If authenticated user tries to access a restricted resource

Question

If a user with authorization to access Resource A, tries to access Resource B (by trying to follow a URL), which of the following is a better course?

1. Take them to a standard Access Denied Page, with a generic, "You do not have sufficient authority to access this resource".
2. Or just ignore their request, no acknowledgement of any kind.

For a malicious user the latter approach seems appropriate, however, for a genuine user, making an honest mistake, the former approach seems better.

Is there an established guideline one could follow?

Answer 1

It is possible to enumerate resources through distinctions such as these - if you return a 403 for pages that do exist, but the current user can't access, and 404 for pages that don't exist, an attacker can easily distinguish between valid and invalid resources.

Whether this matters depends on your application - if you reveal information in this circumstance that has value, it may be a bad thing: if /user/73463 gives me a 404 but /user/64500 gives me a 403, I can make an educated guess that 64500 is a valid user whose profile I can't see. On the other hand, if /year/2003 to /year/2016 give me a 403 but /year/2002 and /year/2020 give me a 404, all I can tell is that you've not created year folders off into the distant future, and possibly that you don't have anything from before 2003.

Ideally, you don't want to provide URLs to which the user has no access (from your question, I'm not sure if the URL being followed is on your site, or from elsewhere). You can only control this within your system though - if user B sends user A a link, user A can discover that the resource exists without caring about your response to them. That applies if a link is provided on a third party website too - no-one is likely to link to a non-existent resource (although they might have linked to a resource that no longer exists, in which case a 404 or 410 would be appropriate). For your own systems, you should aim to minimise the chances that a legitimate user can follow a link to a resource which they don't have permission to access.

Generally, if something can easily be enumerated (e.g. numeric identifier) it makes more sense to return a consistent response to all requests, whether the actual status is lacking authorisation or the resource not existing. If something can't be enumerated (e.g. long hash identifier), it might make sense to distinguish between the states, but you should be aware of the potential for someone to stumble across resources they shouldn't be able to detect, and take steps to prevent this (e.g. monitor for high request rates and throttle apparent attempts to enumerate for resources).

Answer 2

Don't ruin your users' lives. If they made a genuine mistake, or were given a link from another user who is authorised to access the page, it is useful information for them to know that they don't have sufficient permissions. There will be cases where they have a legitimate claim to accessing the information and will then be able to ask another authorised user for help or to turn to the authorisation processes that exists in your system. If you tell them a resource doesn't exist instead you're just adding to their cognitive load and making it harder for them to resolve the situation at hand and get their work done.

Conclusion from a usability perspective: always clearly explain why access is denied.

Now in the case of a public website with authenticated spaces and roles, some will argue that letting people know about unauthorised resources allows malicious users to enumerate resources. Firstly, if they're properly protected this is not always an issue (it depends on your application's context, obviously). Secondly, you can log denied accesses to protected resources and spot/ban users that are enumerating (especially if there is a substantial cost to account setup). Thirdly, if you are really worried, you can even go through the inverse process of showing proper error messages to the users you trust and only leaving the untrustworthy ones in the dark (useful if you have both sensitive resource URLs that need not be enumerated + free registration to your system).

In any case, there's no substantial security benefit or even remotely valid reason to complicate your users' lives with cryptic error messages.

PS: there are one or two research papers that propose the idea that security systems should never provide feedback; without any evidence that the benefits outweight the cost. If anyone's in the mood to argue I'm happy to take one of those and debunk it for you. Basic training in interaction design or usability research will suffice to explain why you must provide valuable error messages to users: the usability cost of not providing feedback is very real and noone in the usability research field would argue about it.