1. Understanding the Modern Threat Landscape
Today's web applications face a constantly evolving array of security threats. Understanding these threats is the first step in building robust defenses. The OWASP Top 10 provides a framework for the most critical web application security risks.
The OWASP Top 10:2025
OWASP's current Top 10 is an awareness guide, not a complete security standard. Use it to prioritize work, then apply a testable standard such as OWASP ASVS for systems that handle accounts, payments, or sensitive data. The sections below give a small, defensive example for each 2025 category. Read the current OWASP Top 10:2025 documentation alongside this guide.
A01: Broken Access Control
Example: A signed-in user changes
/api/invoices/1042 to another invoice ID and can read someone else's data. Authorize on the
server for every request, using the authenticated identity and resource ownership; never rely on hidden
buttons or a client-side role check.
A02: Security Misconfiguration
Example: A production error page exposes a stack trace, database host, and framework version. Use hardened production settings, remove default accounts and sample routes, keep security headers deliberate, and review infrastructure changes before release.
A03: Software Supply Chain Failures
Example: A build downloads a package by a floating version and a compromised update runs in CI. Lock and review dependency versions, protect CI credentials, restrict who can change build workflows, and verify provenance or checksums for critical artifacts.
A04: Cryptographic Failures
Example: Password reset tokens are sent over HTTP or card data is stored in readable form. Enforce HTTPS, use well-maintained library defaults rather than custom cryptography, encrypt sensitive data where necessary, and keep keys outside the codebase.
A05: Injection
Example: A search term is joined directly into a SQL statement, allowing it to change the query's meaning. Use parameterized queries or safe ORM bindings, allow-list any dynamic identifiers such as sort columns, and encode output for its exact HTML, URL, JavaScript, or CSS context.
A06: Insecure Design
Example: A password-reset flow has no expiry, rate limit, or identity verification, even though each endpoint is coded correctly. Threat-model important flows early, write abuse cases, define security requirements, and test whether controls still hold when an attacker automates the process.
A07: Authentication Failures
Example: An application accepts reused passwords with unlimited login attempts and keeps the same session identifier after login. Offer MFA where appropriate, rate-limit and monitor login attempts, hash passwords with Argon2id, bcrypt, or scrypt, and rotate session identifiers after authentication or privilege changes.
A08: Software or Data Integrity Failures
Example: A webhook is processed without verifying its signature, or a serialized object from an untrusted source is deserialized. Verify signatures before processing data, use signed updates and trusted sources, and avoid unsafe deserialization formats for untrusted input.
A09: Security Logging and Alerting Failures
Example: A large burst of failed sign-ins is neither recorded nor alerted on, so a credential-stuffing attack is found weeks later. Log authentication, authorization, and sensitive-data events without storing secrets; centralize logs, protect them from alteration, and alert on defined suspicious patterns.
A10: Mishandling of Exceptional Conditions
Example: When a payment provider times out, an order is marked paid anyway; when a file parser fails, the application exposes details or continues with partial data. Define safe failure states, validate recovery paths, use timeouts and limits, return generic user-facing errors, and record enough internal context to investigate.
Use This as a Starting Point
A checklist is useful, but it does not replace design review, automated testing, or independent security assessment. Prioritize the risks that match the data, permissions, integrations, and threat model of your application.