Authorization Header Security Testing: Test Cases for Broken Auth Issues

When you’re diving into a security assessment, the Authorization header is often where critical vulnerabilities hide. Finding these flaws like broken authentication or unauthorized access, requires a systematic approach. That’s exactly why I put together this practical guide of essential authorization header test cases for penetration testers.

Think of this as your go-to checklist for validating how robust an application’s authorization really is. For all these tests, I assume you are already set up to intercept network requests (Burp Suite or Owasp ZAP) and are ready to manipulate the header to observe the server’s response.

Test Case Matrix

Category 1: Missing or Malformed Headers

This category tests how the server enforces the presence and basic format of the header for protected resources.


Sr no	Testcase	Steps (with testcase example)	Expected
1.1	Missing Header	Send the request without the Authorization header.	401/403: The server must reject access to protected resources.
1.2	Empty Header	Send the request with an empty Authorization header. `Authorization:`	401/403: The server must reject the request.
1.3	Scheme Only	Send the request with only the authentication scheme but no token. `Authorization: Bearer`	401/403: The server must reject the request as no token is provided.
1.4	Malformed/Garbage Value	Replace the valid token with a completely random or garbage string. `Authorization: xyz123`	401/403: The server must reject the unrecognizable token.
1.5	Standard Invalid Tokens	Use common programming null/boolean values as the token. Authorization: Bearer null Authorization: Bearer undefined	401/403: The server should not misinterpret these values and must reject them.
1.6	Fuzzed Token (Tail)	Add extra characters to the end of a valid token. `Authorization: Bearer <valid_token>abcdef`	401/403: The token should be validated as a whole and rejected as invalid.
1.7	Truncated Token	Remove characters from the end of a valid token. `Authorization: Bearer <token_prefix>`	401/403: The partial token must be rejected.

Category 2: Scheme and Parser Manipulation

This category tests how strictly the server parses the header scheme and value, looking for bypasses in parser logic.


Sr no	Testcase	Steps (with testcase example)	Expected
2.1	Scheme Manipulation	Change the expected scheme (e.g., Bearer) to another common scheme. `Authorization: Basic <token> Authorization: Digest <token>`	401/403: The server must enforce the expected scheme (e.g., Bearer) and reject others.
2.2	Scheme Removal	Remove the scheme-prefix entirely, sending only the token. `Authorization: <token>`	401/403: The server should expect a scheme and reject the request.
2.3	Scheme Case Insensitivity	Change the case of the scheme name (per RFC 2617, this should be case-insensitive, but test for bypasses). `Authorization: bearer <token>`	Success or 401: The server should consistently process it (either accept or reject) but not lead to an auth bypass.
2.4	Whitespace Fuzzing	Add extra spaces or non-standard whitespace (tabs \t) between the scheme and token. `Authorization: Bearer <token>Authorization: Bearer \t <token>`	401/403: A loose parser might be bypassed. A strict parser should reject it.
2.5	Header Name Case Insensitivity	Change the case of the header name (per H2/H3, this is lowercase, but H1 is not). `authorization: Bearer <token>`	Success or 401: The server should treat all as equivalent and validate properly. Test for bypasses.
2.6	Header Splitting (CRLF)	Inject CRLF characters (%0d%0a) into the token value to attempt header injection. `Authorization: Bearer <token>%0d%0aX-Role: admin`	400/401: The server must reject the malformed header and not process any injected headers.
2.7	Null Byte Injection	Inject a null byte (%00) into the token. `Authorization: Bearer <valid_token>%00`	401/403: If the server is C-based, this might truncate the token, leading to a bypass. It should be rejected.

Category 3: Token Validity and Lifecycle

This category ensures the server properly validates the token’s lifecycle and issuance context.


Sr no	Testcase	Steps (with testcase example)	Expected
3.1	Expired Token	Use a token that is past its exp (expiration) claim.	401/403: The server must validate the exp claim and reject the expired token.
3.2	Revoked Token	Use a token that was explicitly revoked (e.g., after a logout or password reset action).	401/403: The server must check against a revocation list (blacklist) and reject the token.
3.3	Cross-Environment Token	Use a token issued for a different environment (e.g., a “dev” token on “prod”).	401/403: The server should validate the token’s issuer (iss) or audience (aud) and reject it.
3.4	Replay Attack	Re-send a valid request multiple times. This is especially relevant for tokens with a nonce.	401/403: If the token is one-time-use (nonce-based), it should fail.
3.5	Old Token After Refresh	Use an old access token immediately after using a refresh token to get a new one.	401/403: The server should ideally invalidate the old access token upon refresh.

Category 4: Privilege Escalation

This category tests if the token’s identity is correctly mapped to its permissions.


Sr no	Testcase	Steps (with testcase example)	Expected
4.1	Vertical Privilege Escalation	Use a valid token from a low-privilege user to access an admin-only endpoint. `GET /api/admin/users Authorization: Bearer <user_token>`	403 Forbidden: The server must deny access based on the user’s role/permissions.
4.2	Horizontal Privilege Escalation (BOLA/IDOR)	Use User A’s valid token to access User B’s private resources. `GET /api/users/userB_id/profile Authorization: Bearer <userA_token>`	403 Forbidden: The server must validate that the token’s owner matches the resource owner.
4.3	Custom Role Header	Send a valid token and a custom header attempting to override the role. `Authorization: Bearer <user_token> X-Role: admin`	403 Forbidden: The server must ignore any client-supplied headers and trust only the claims within the token.

Category 5: JWT-Specific Attacks

This category targets vulnerabilities specific to the implementation of JSON Web Tokens.


Sr no	Testcase	Steps (with testcase example)	Expected
5.1	‘None’ Algorithm	Change the JWT header alg claim to none (case-sensitive) and remove the signature. `Header: {"alg":"none"}Signature: (empty)`	401/403: The server must explicitly reject tokens with alg: none.
5.2	Claim Manipulation (No Signature)	Decode the JWT, change claims (e.g., “role”:”user” to “role”:”admin”), and send without re-signing.	401/403: This tests for a total lack of signature verification.
5.3	Algorithm Confusion (RS256 to HS256)	Change the alg to HS256 (symmetric) and re-sign the token using the server’s public key as the HMAC secret.	401/403: The server must not confuse public keys with symmetric secrets.
5.4	Weak Secret (HS256)	Attempt to brute-force the HMAC secret offline. If successful, forge a new token with admin claims.	Success: This is an offline attack. If the secret is weak (e.g., ‘secret’), new tokens can be forged.
5.5	Audience (aud) Mismatch	Use a valid token issued by the same provider but for a different application (mismatched aud claim).	401/403: The server must validate the aud claim matches its own identifier.
5.6	jku/kid Header Injection	Modify the JWT header to point to a jku (JWK Set URL) or kid (Key ID) that is controlled by the attacker. `Header: {"alg":"RS256", "jku":"http://attacker.com/key.json"}`	401/403: The server must only use a trusted allowlist of jku/kid references.

Category 6: Architectural and Edge Cases

This category tests for flaws in how the Authorization header interacts with other parts of the application architecture.


Sr no	Testcase	Steps (with testcase example)	Expected
6.1	Header Duplication	Send two Authorization headers (one valid, one invalid) to see which one the server processes. `Authorization: Bearer <invalid_token>Authorization: Bearer <valid_token>`	400/401: The server should reject the ambiguous request or have a well-defined (and secure) processing order.
6.2	Alternative Headers	Test for alternative headers sometimes accepted by frameworks. `X-Auth-Token: <token> Authorisation: Bearer <token>`	401/403: Should be rejected unless explicitly documented.
6.3	HTTP Method Manipulation	Change the request method (e.g., POST to OPTIONS or HEAD) to see if authorization is inconsistently applied. `OPTIONS /api/admin/users`	401/403: Auth must be enforced on all methods for protected endpoints (including OPTIONS).
6.4	Token via Query String	Remove the header and pass the token in the URL query string. `GET /api/resource?access_token=<token>`	401/403: Accepting tokens in URLs is a high-risk practice (leaks in logs, referer) and should be rejected.
6.5	Token via Request Body	Remove the header and pass the token in the request body. `{"access_token": "<token>"}`	401/403: Should be rejected unless this is a documented part of the flow (e.g., token endpoint).
6.6	Conflicting Auth Methods	Send a valid session cookie and an invalid Authorization header (and vice-versa).	Defined Behavior: The server must have a clear precedence (e.g., “Always trust Bearer token for APIs”).
6.7	Method Override Bypass	Send a GET request (which might have weaker auth) but add a method-override header. `GET /api/resource X-HTTP-Method-Override: POST`	401/403: Auth checks for the overridden method (POST) should be applied.
6.8	Cache Poisoning	Send an authorized request and check if the sensitive response is cached (e.g., missing Cache-Control: private). Then, access the same URL without the header.	Cache-Control: private: Sensitive data must never be stored in a shared cache.
6.9	Information Leakage	Send malformed tokens (e.g., invalid Base64 for Basic) to check for verbose error messages. `Authorization: Basic AAAA`	Generic 400/401: Errors must not leak stack traces, internal paths, or framework details.
6.10	SQLi via Token	Inject SQL-specific characters (e.g., ‘) into the token value. `Authorization: Bearer <token>'`	401/403: The token should be treated as a string, not executed. A 500 error indicates a likely SQLi.
6.11	Rate Limiting	Brute-force many different Basic auth credentials or JWTs rapidly. `Authorization: Basic YWRtaW46MTIzNA== Authorization: Basic YWRtaW46MTIzNQ==`	429 Too Many Requests: The auth verification endpoint must be rate-limited.
6.12	Size Overflow	Send an extremely long token (>8KB) to test server header size limits. `Authorization: Bearer AAAA...[8KB]...AAAA`	413/431: The server should reject oversized headers gracefully, not crash (DoS).