Authentication, Logic & Architecture Flaws.

Password recovery — recurring flaws

• Predictable tokens. Reset tokens based on timestamp + user-ID. Test by requesting two resets seconds apart and diffing the tokens.
• Response timing leak. POST /forgot-password {email:x@y} returns 200 in 80ms for non-existent users, 300ms for existing. Username enumeration via timing.
• Body-shape leak. "We have sent an email" vs "If the address exists, an email has been sent". The first is leaky.
• Token reuse / non-expiry. Same token works after first use; valid for days, not minutes.
• Second-factor downgrade. Password reset bypasses TOTP. After reset, user is logged in with no MFA challenge.
• Reset link includes session token. Sharing the reset link with a co-worker shares the session.
• Host header injection. Host: attacker.com in reset request causes the email to contain a link pointing at attacker. Common in apps that use the Host header to construct the reset URL.

JWT — common misuses

• alg: none. Re-sign token with header {"alg":"none"} and empty signature. Server accepts if it didn't whitelist algorithms.
• HS256 with RSA public key. Server expects RS256 but accepts HS256. Attacker uses the public RSA key as the HMAC secret → forges any token.
• Key-ID injection. kid header used in SELECT key FROM keys WHERE id=? without parameterization → SQL injection. Or kid: ../../../etc/passwd for file read.
• Audience claim ignored. Token issued for service A accepted by service B with the same signing key. Cross-service replay.
• Expiry ignored. Token from last quarter still accepted.
• Defense. Hard-code allowed algorithm. Validate iss, aud, exp, nbf explicitly. Reject tokens with unexpected headers.

CORS misconfigs

• Reflect-and-allow-credentials. Server reads Origin, echoes it as Access-Control-Allow-Origin, sets Allow-Credentials: true. Any attacker site can read authenticated responses.
• Null origin allowed. Sandbox iframes and data: URLs send Origin: null. Allowing this lets a sandboxed page exfil.
• Subdomain wildcard. *.example.com trusted; attacker takes over a forgotten subdomain → trusted origin.
• Test. Send request with Origin: https://attacker.com. If response contains Access-Control-Allow-Origin: https://attacker.com + Allow-Credentials: true, it's exploitable.

API-first pitfalls

• Mass assignment. PATCH /user/me {role:"admin"} accepted because the JSON deserializer binds all fields by default (Rails strong-params off, Spring no DTO).
• GraphQL introspection in production. {__schema{types{name,fields{name}}}} returns the full schema. Find hidden mutations.
• GraphQL query-cost DoS. Nested query: {user{posts{user{posts{user{posts{id}}}}}}}. No depth/cost limit = single request takes down the server.
• Batched mutation auth. Auth check on single-mutation endpoint, missing on batched-mutation endpoint.
• HTTP method override. POST with X-HTTP-Method-Override: DELETE bypasses a WAF rule that filtered on DELETE.

Working top-10 business-logic flaws

1. Negative quantity. Cart accepts quantity: -3; total goes negative; refund issued.
2. Discount stacking. Two single-use codes applied via parallel requests.
3. Step-skipping. Direct POST to step 5 of a 5-step wizard without completing steps 1–4.
4. Race-condition double-spend. Two concurrent withdrawal requests, balance decremented once.
5. Currency rounding abuse. Buy 0.0001 BTC repeatedly when rounding favors the user.
6. Trial-period reset. Delete account + recreate with same email = new trial.
7. Authorization at the wrong layer. UI hides the admin button but the API endpoint doesn't check role.
8. Cancel after success. Cancel-order endpoint reverses the inventory deduction but not the discount usage.
9. Voucher / referral exploit. Self-referral via two accounts, both get the bonus.
10. State-machine bypass. Order goes from PENDING straight to FULFILLED without PAID.