Don't take my word for it.

1. → GET /api/invoices/10422 Authorization: Bearer <customer A>
2. ← 200 OK { id: 10422, customer: "A", total: "₹2,40,000" }
3. → GET /api/invoices/10423 Authorization: Bearer <customer A> ← next id, same token
4. ← 200 OK { id: 10423, customer: "B", total: "₹1,10,000" }
5. The id is sequential and the server never checks who is asking.
6. Severity: High (CVSS 7.5) · Broken object-level authorisation (OWASP API1)

The fix. One authorisation check at the data layer — invoice.ownerId === session.userId — and ids moved to non-guessable values. Two files.

1. → POST /auth/reset { "email": "me@corp.com", "token": "9f2c…", "newPassword": "…" }
2. ← 200 OK { "reset": true }
3. → POST /auth/reset { "email": "admin@corp.com", "token": "9f2c…" } ← my token, their email
4. ← 200 OK { "reset": true } ← should have been 403
5. The token was validated, but never tied to the email it was issued for.
6. Severity: Critical (CVSS 9.1) · Account takeover, no interaction

The fix. Bind the reset token to the account it was issued for, expire it on use, and rate-limit the endpoint. Caught in the final-week attack, never shipped.

1. → GET / (the same six checks this page runs on your domain)
2. ← no CSP · no HSTS · X-Frame-Options missing · SPF/DMARC absent
3. Grade F on headers, and the domain could be spoofed in email.
4. Severity: Medium, but it's the first thing a buyer or attacker checks.

The fix. A strict Content-Security-Policy with nonces, HSTS, a frame policy, and the three hygiene headers — plus SPF and DMARC records so the domain can't be forged. The same set this site scores A on.