The OWASP Top 10 (SQL injection, XSS, CSRF, etc.) is well-documented and most developers know the basics. Here are the security patterns that are less commonly implemented correctly, drawn from real vulnerability patterns in 2024–2026.
The Indirect Object Reference Problem
Insecure Direct Object Reference (IDOR) is consistently one of the most commonly found vulnerabilities in bug bounty programmes, despite being simple to understand and prevent. The pattern: your API returns `/api/orders/12345` and the user can change `12345` to `12346` to see someone else’s order — because the code only checks authentication (is this user logged in?) not authorisation (does this user own order 12346?). The fix: always verify that the requesting user has permission to access the specific resource they are requesting. A simple rule: never expose database IDs directly to the frontend; if you must, verify ownership on every request. Better: use UUIDs instead of sequential integers (harder to guess) but still verify ownership. The pattern in authorisation bugs: most authorisation bugs are not “the check doesn’t exist” — they are “the check exists for one endpoint but was forgotten for another endpoint that provides the same data through a different path.” Audit all paths to sensitive data.
Rate Limiting: Not Just for APIs
Rate limiting is commonly applied to login endpoints to prevent brute force attacks. Less commonly applied: account creation (allowing attackers to create thousands of accounts for spam, credential stuffing testing, or resource exhaustion); password reset (allowing rapid enumeration of which email addresses have accounts); checkout/payment flow (allowing cart stuffing or inventory manipulation); search endpoints (enabling data scraping). The correct approach: rate limit by IP, by account, and by action type. Also consider: exponential backoff for failed authentication attempts (block for 1 second after first failure, 2 after second, 4 after third, etc.) and account lockout after N consecutive failures (with CAPTCHA unlock rather than email unlock, to prevent denial-of-service through deliberate lockout of other accounts).
The JWT Misuse Problem
JSON Web Tokens (JWTs) are widely used for authentication but frequently misused. Common mistakes: trusting the algorithm specified in the JWT header — the `alg: “none”` attack allows an attacker to strip the signature and set the algorithm to “none,” causing some implementations to accept unsigned tokens; using asymmetric key pairs (RS256) but verifying with the public key as an HMAC secret (confusion attack); storing sensitive data in JWT payloads (JWTs are base64 encoded, not encrypted — anyone can decode the payload). The correct pattern: fix the algorithm in your verification code (do not read it from the token header); use a short expiry (15 minutes for access tokens, longer for refresh tokens); revoke refresh tokens on logout (maintain a token revocation list or use token families); never store passwords, payment data, or other sensitive information in JWT payloads.
Dependency Security
The most underappreciated attack surface in 2025–2026: supply chain vulnerabilities via npm/PyPI/Maven packages. The `event-stream` incident (2018), `log4shell` (2021), `polyfill.io` (2024), and numerous smaller incidents show that third-party dependencies are a major attack surface. Practical measures: run `npm audit`, `safety check` (Python), or `snyk test` in your CI pipeline; pin dependency versions (do not use `^1.x.x` or `~1.2.x` in production — pin to exact versions); check the provenance of dependencies you add (does this package have one maintainer? Is it regularly updated? How many weekly downloads does it have? Is it owned by a company or an individual?); SBOM (Software Bill of Materials): generate and maintain a list of all dependencies and their versions, enabling rapid assessment when a new vulnerability is announced.
