4 ms·

On the client side, whether a GET returned a successful (2xx) or error (4xx/5xx) status is observable for cross-origin requests. This can leak information about

On the client side, whether a GET returned a successful (2xx) or error (4xx/5xx) status is observable for cross-origin requests. This can leak information about the user, particularly if you have cookie-authenticated resources that 503 depending on the user's identity (e.g. Facebook 503ing if you're not friends with X). This can be resolved by requiring a CSRF token or fancy header, but that muddles the RESTful semantics. A common solution is to make your public API RESTful and authenticated differently from your browser cookie sessions, and make the private web APIs always return 200.

TheAndruu 11y ago
403 would be the proper status if the user was authenticated but forbidden. 503 would imply an error on the server and that the service is unavailable. Here the 403 is appropriate because the user is logged in and trusted to some degree by your system, but isn't allowed to access that URI. If the user were unauthenticated and tried to access the same URL, he should get a 401 for Unauthorized, which is the same response he should get for every URI in your system, thus exposing nothing about your underlying service.
- nitrogen 11y ago
  GitHub returns 404 instead of 403 to prevent these information leaks.
  - dragonwriter 11y ago
    > GitHub returns 404 instead of 403 to prevent these information leaks. This behavior is explicitly permitted by the standard, FWIW: An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found). https://tools.ietf.org/html/rfc7231#section-6.5.3 https://tools.ietf.org/html/rfc7231#section-6.5.3
- chromakode 11y ago
  Ah yes, thank you, that should have been 403. I suspect a 401 would still leak info, as the <img> or <script> tag will let you differentiate between a 200 and other failing status.
e12e 11y ago
I'm not sure I follow how something that's wrapped in a TLS session can leak information if it's returned as an encrypted header, but not if it's returned as an encrypted body?
- nitrogen 11y ago
  Maybe they do <img src="API" onerror="gotcha()">?

TheAndruu 11y ago

403 would be the proper status if the user was authenticated but forbidden. 503 would imply an error on the server and that the service is unavailable. Here the 403 is appropriate because the user is logged in and trusted to some degree by your system, but isn't allowed to access that URI. If the user were unauthenticated and tried to access the same URL, he should get a 401 for Unauthorized, which is the same response he should get for every URI in your system, thus exposing nothing about your underlying service.

nitrogen 11y ago
GitHub returns 404 instead of 403 to prevent these information leaks.
- dragonwriter 11y ago
  > GitHub returns 404 instead of 403 to prevent these information leaks. This behavior is explicitly permitted by the standard, FWIW: An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found). https://tools.ietf.org/html/rfc7231#section-6.5.3 https://tools.ietf.org/html/rfc7231#section-6.5.3
chromakode 11y ago
Ah yes, thank you, that should have been 403. I suspect a 401 would still leak info, as the <img> or <script> tag will let you differentiate between a 200 and other failing status.

e12e 11y ago

I'm not sure I follow how something that's wrapped in a TLS session can leak information if it's returned as an encrypted header, but not if it's returned as an encrypted body?

nitrogen 11y ago
Maybe they do <img src="API" onerror="gotcha()">?