I'm having a discussion with devs as we build out a web app which involves users, user generated content, an admin area, api and static content.

Anyone is able to access the majority of template information such as the user account template where users would view and update their information, the template url requires very little digging to find and no authentication to request. Same goes for the majority of administration templates, none of which will function correctly without the correct authentication but it's still accessible for reading.

This allows anyone (authenticated users especially) to gain a solid understanding of how the web app and API's function. Preventing access to this information would only provide a layer of obscurity as the API methods and internal functions would still operate the same - people would just have to make more assumptions.

Currently our reasonings are,

Yes we should prevent access: Only provide resources as required, anything more will encourage malicious behaviour.

No we shouldn't prevent access: It's a lot of extra work, it adds complexity and if we have a security issue this would only provide obscurity.

So my question is:

should we (and do others) prevent access to this type of non-sensitive information?

After further discussion, someone suggested this nightmarish policy:

graphical resources, such as the sign-out icon, should only be available to authenticated users and origins which are expected to display the icon.

  • The policy is not so nightmarish to implement. If you use a db, which holds a table with all resources a page needs, a table whixh usergroup can access what pages then you can easily generate a query to decide who can access what resource.
    – Falco
    Commented Aug 24, 2016 at 7:38
  • @Falco implementing it might be possible in a very basic sense, logging violations of the policy (and ones like it) are what I'd have concerns about, especially where user generated content is the target.. plus the page speed / caching guy would probably quit
    – 8eecf0d2
    Commented Aug 24, 2016 at 8:00

2 Answers 2


Don't prevent access. Don't make things hard for your team. Don't introduce gratuitous complexity, it is the enemy of security, and a sure path to technical debt. Don't look to obfuscation, to an attacker that is a clear sign that more obvious defenses have been overlooked.

  • I agree, although both sides can be argued, not preventing access to this information should encourage better security where it matters and the resources required to manage policies as well as logging and acting upon violations would be tremendous.
    – 8eecf0d2
    Commented Aug 25, 2016 at 1:58

This basically boils down to how confident you are that your implementation is secure.

If there are vulnerabilities that can be discovered by examining this "non-sensitive information", then it would be wise to obscure it while you work on fixes.

If however, you have had an audit, penetration test, security assessment, or other security test carried out on your implementation and have no concerning vulnerabilities, then it is not worth the effort in obscuring it for the sake of it.

  • 3
    An important thing to add to this is that you are aware of the data being available. Make sure that this is documented, along with the reasoning why, and then should you have an assessment which highlights it, you can return to management with the reasoning and make it clear why this choice was made. Problems tend to occur when this sort of detail is forgotten, and sensitive data is added to public files (e.g. someone adds a comment which isn't intended for public consumption).
    – Matthew
    Commented Aug 24, 2016 at 14:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .