OWASP Top 10 Study Portal

A: It moved to the #1 position. It was the most serious risk found in the contributed test data — 94% of tested applications had some form of broken access control — so it rose from #5 to the top of the list.

A: A04 Insecure Design, A08 Software and Data Integrity Failures, and A10 Server-Side Request Forgery (SSRF).

A: The old name described a symptom (data was exposed) rather than the cause. The 2021 list refocuses on the root cause — failures in, or absence of, cryptography — which is more actionable for engineers.

A: Insecure Design is a flaw in the control design itself — it exists before any code is written and cannot be patched by configuration. Misconfiguration is a correctly designed control set up incorrectly. You fix design with threat modeling; you fix misconfiguration with hardening.

A: Parameterized queries / prepared statements (or a safe ORM), so untrusted input is always treated as data and never as executable code or query structure.

A: In 2021 it was merged into A03 Injection, because XSS is fundamentally an injection problem — untrusted input being interpreted in a new context (the browser/HTML/JS interpreter).

A: An Insecure Direct Object Reference — accessing another user's object by manipulating an identifier (e.g. an account ID in a URL). It belongs to A01 Broken Access Control.

A: With a salted, memory-hard, adaptive key-derivation function such as Argon2id, scrypt, or bcrypt — never plaintext, never fast general-purpose hashes like MD5 or SHA-256 alone.

A: XML External Entities (XXE), which was its own category in 2017, is now folded into Security Misconfiguration.

A: Insecure Deserialization (a standalone 2017 category) is now part of A08, alongside unsigned updates and insecure CI/CD pipelines.

A: Server-Side Request Forgery tricks the server into making requests to attacker-chosen destinations. In the cloud it's especially dangerous because it can hit the instance metadata endpoint (169.254.169.254) to steal IAM credentials.

A: Without logging and alerting, breaches go undetected for long periods, turning a containable incident into a major, prolonged compromise. The risk is in the time-to-detect, which dynamic testing rarely surfaces.

A: No. It is an awareness and prioritization document. For verification use OWASP ASVS, and for building secure controls use the OWASP Proactive Controls.

A: Deny by default and enforce authorization server-side in trusted code on every request, checking object ownership — never rely on the client or UI to hide functionality.