Lesson 1 of 85 min read
Authentication vs authorization (401 vs 403)
Two words that sound alike but test very different things. Mixing them up is a common interview slip.
Key takeaways
- 1Authentication = who are you? (login, token). Failure returns 401 Unauthorized.
- 2Authorization = what are you allowed to do? (roles, ownership). Failure returns 403 Forbidden.
- 3Some APIs return 404 instead of 403 to hide that a resource exists. Both are acceptable if documented.
Quick check
GET /orders/55 with no token -> 401 (not logged in) GET /orders/55 with Ravi's token -> 403 (order belongs to Asha) GET /orders/55 with Asha's token -> 200 (her own order)
Go deeper
Expert notes beyond the basics
- 01
Where 404 fits in the picture
Some APIs deliberately return 404 Not Found instead of 403 Forbidden when a user tries to access someone else's resource, so an attacker cannot tell the difference between 'does not exist' and 'exists but is not yours'. For example GET /invoices/900 for an invoice owned by another customer may return 404 rather than 403. When you test this, check the API documentation or ask the developer which behaviour is intended, then verify every endpoint follows the same rule consistently, because mixing 403 and 404 across endpoints leaks information.
- 02
Testing 401 across every protected endpoint
Do not just test 401 on one login call. Build a small list of every protected endpoint (GET /me, GET /orders, POST /cart, DELETE /account) and call each one with no Authorization header, an empty header, a malformed header like 'Bearer' with nothing after it, and a header with extra spaces. In Postman, you can create a collection where every request is sent twice: once with the saved token variable and once with it cleared, using a pre-request script to strip the header, so you catch endpoints that forgot to add the auth check.
- 03
403 bodies should not leak details
When an API returns 403, check the response body carefully. A bad response might say 'User ravi@x.com does not have role ADMIN required for this resource', which confirms the account's role and email exist and reveals internal role names. A good response says only something generic like 'You do not have permission to perform this action'. Flag any 403 or 401 body that echoes back sensitive request data, internal IDs, stack traces, or SQL fragments as a security bug, even if the status code itself is correct.
- 04
Chaining authentication and authorization checks
Many real bugs happen at the boundary between the two concepts. Test sequences such as: log in as a normal user, then let the session or token expire, then immediately try an admin action; or get authenticated as user A, then switch roles mid-session (if the API allows a role change) and check old tokens are revalidated. In Postman you can script this with a collection runner: request 1 logs in, request 2 waits past token expiry using a delay, request 3 calls a protected endpoint and asserts status equals 401, not 403 or 200.
Common mistakes to avoid
- - Testing 401 and 403 only on the login endpoint instead of every protected route.
- - Accepting a 403 response body that reveals the user's real role, email or internal IDs.
- - Not checking whether the API consistently chooses between 403 and 404 for unauthorized access to someone else's data.
- - Treating a 500 error returned for a missing token as acceptable, when it should be a clean 401.
Try it yourself
An API has GET /account/settings (requires login) and GET /account/settings/billing (requires login plus an active paid plan). Write the test cases you would run to confirm 401 and 403 are both used correctly, including request details.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
What is the difference between 401 and 403?
Model answer
401 means the request isn't authenticated: no token, or an invalid or expired one. 403 means the user is authenticated but not allowed to perform this action or see this resource.
- Q2
If an endpoint returns 500 instead of 401 when no token is sent, is that a bug?
Model answer
Yes. A missing or invalid token should always produce a clean 401 Unauthorized. A 500 means the server crashed while trying to process the request, which is a reliability and security concern since it may leak a stack trace, and it also means the auth check happened too late or not at all.
- Q3
Should a public endpoint, like a product listing, ever need authentication?
Model answer
Not necessarily. Some APIs intentionally allow anonymous read access to public data but still enforce authentication for actions like adding to cart or checkout. As a tester I confirm with the requirements which endpoints are meant to be public, then verify private endpoints reject anonymous calls and public ones still work without a token.
- Q4
How would you explain 401 vs 403 to a non-technical stakeholder?
Model answer
401 is like being asked to show ID at the door and you have none or a fake one, so you are not let in at all. 403 is like showing valid ID but the venue still will not let you into the VIP area because your ticket does not cover it. One is about who you are, the other is about what you are allowed to do.
Knowledge check
+5 points
A logged-in normal user calls an admin-only endpoint. Expected status?