How to Secure Your Web Application Against the OWASP Top 10

The OWASP Top 10 is a consensus list of the most critical security risks to web applications, maintained by the Open Web Application Security Project and updated every three to four years based on real-world breach data. It matters right now because these aren't theoretical risks — they're the actual categories behind the majority of reported web application compromises, and they affect applications built with every tech stack, at every scale. If your team hasn't walked through this list as a structured review of your own application, this is where to start.

A1: Broken Access Control

The top-ranked risk since 2021, broken access control means users can act outside their intended permissions — accessing other users' data, escalating their own privileges, or reaching administrative functions without authorization. This is consistently the most commonly found vulnerability in real-world testing.

Practical defenses:

• Deny by default at the server side. Never rely on the UI hiding something as a security control — always enforce authorization on the API endpoint itself.
• For multi-tenant SaaS applications, every database query that returns user-specific data should include the authenticated user's ID as a constraint. A request for /api/invoices/1042 should verify that invoice 1042 belongs to the requesting user, not just that the user is authenticated.
• Log access control failures and alert on patterns — repeated 403 errors from the same session are a signal worth investigating.
• For role-based systems, implement a centralized authorization layer rather than scattering permission checks throughout the codebase. Libraries like Casbin or OPA (Open Policy Agent) provide structured policy enforcement.

A2: Cryptographic Failures

Previously called "Sensitive Data Exposure," this category covers situations where sensitive data is inadequately protected — transmitted in clear text, stored with weak or no encryption, or protected with deprecated algorithms.

Practical defenses:

• Identify what data in your application is genuinely sensitive: passwords, payment data, health information, session tokens, API keys. Each category may have different requirements.
• Passwords must be stored as hashes using a work-factor algorithm: bcrypt, scrypt, or Argon2. MD5 and SHA-1 are not acceptable for password storage in any new system.
• Enforce HTTPS everywhere, including internal service-to-service communication. HTTP Strict Transport Security (HSTS) headers prevent downgrade attacks.
• Don't roll your own cryptography. Use established libraries (libsodium, the standard library for your language) rather than custom implementations.

A3: Injection

SQL injection is the most well-known member of this family, but injection vulnerabilities also occur with LDAP, XML, command execution, and template engines. An attacker who can control the structure of a query or command — rather than just the data within it — can read arbitrary data, modify or delete records, or in the worst cases execute commands on the host system.

Practical defenses:

• Use parameterized queries or prepared statements for all database interactions. No string concatenation to build SQL queries. This single control eliminates the vast majority of SQL injection risk.
• Use an ORM that handles parameterization by default — but be aware that raw query escape hatches (like SQLAlchemy's text() with user input) bypass this protection.
• Validate and sanitize inputs that will be used in contexts beyond SQL — OS commands, LDAP queries, XPath, template rendering.
• Apply the principle of least privilege to database accounts: your application's database user should only have permissions it actually needs. A SELECT-only user cannot exfiltrate data by dropping tables.

A4: Insecure Design

This category, added in the 2021 update, addresses architectural and design flaws that no amount of secure implementation can fix after the fact. The key insight is that security needs to be considered during design, not bolted on during code review.

Practical defenses:

• Include threat modeling in your design process for new features. This doesn't require a formal methodology — asking "what's the worst thing someone could do with this feature?" is a starting point.
• Define security requirements alongside functional requirements. "Users can reset their passwords" needs to include requirements about rate limiting, token expiry, and notification to the account owner.
• Challenge business flows that could be abused at scale. A promo code redemption flow that doesn't rate-limit by account or IP invites scripted abuse, regardless of how correctly the code is implemented.

A5: Security Misconfiguration

Cloud environments, web frameworks, web servers, and databases all come with defaults that aren't designed for production security. Security misconfiguration is found in virtually every application assessed in the field.

A6: Vulnerable and Outdated Components

Your application's attack surface extends to every third-party library, framework, and dependency in your dependency tree. The Log4Shell vulnerability in 2021 demonstrated how a single library used transitively by thousands of applications could become a global incident overnight.

Practical defenses:

• Integrate dependency scanning into your CI/CD pipeline. GitHub Dependabot, Snyk, or OWASP Dependency-Check can flag known vulnerabilities automatically.
• Set a policy for how quickly critical CVEs in direct dependencies must be patched. Many teams use a 7/30/90-day SLA for critical/high/medium severities.
• Maintain a software bill of materials (SBOM) if you operate in regulated environments — this is becoming a procurement requirement, particularly for US federal vendors under recent executive orders.

A7: Identification and Authentication Failures

Weak authentication, broken session management, and missing account protection enable credential stuffing, brute force attacks, and session hijacking.

Practical defenses:

• Rate-limit and lock authentication endpoints. A login form without rate limiting will be credential-stuffed eventually.
• Require MFA for all users; make it mandatory for admins and billing contacts. TOTP apps or hardware keys are preferable to SMS.
• Generate session tokens with a CSPRNG; minimum 128 bits of entropy; invalidate on logout and password change.
• Check passwords against breached credential databases (the Have I Been Pwned API offers a free, privacy-preserving lookup).

A8 and A9: Integrity Failures and Logging Gaps

A8 (Software and Data Integrity Failures) covers scenarios where code or data is used without integrity verification — insecure deserialization, CI/CD pipeline compromise, and unverified auto-updates. Practical defenses: pin GitHub Actions to specific commit hashes rather than mutable tags; use Subresource Integrity (SRI) hashes when loading JavaScript from third-party CDNs; verify checksums on downloaded dependencies in your build pipeline.

A9 (Security Logging and Monitoring Failures) addresses the detection gap — applications that don't log authentication failures, access control violations, or high-value transactions give attackers the time they need. Log all authentication events, access denials, and admin actions. Don't log sensitive values (passwords, tokens, card numbers). Ship logs to a location the application cannot modify, and alert on anomalies: login rate spikes, geographic access changes, large unexpected data exports.

A10: Server-Side Request Forgery (SSRF)

SSRF occurs when an application fetches a remote resource based on a URL supplied by the user, and an attacker supplies a URL pointing to an internal service — the instance metadata service on AWS (http://169.254.169.254), an internal database, or another service not accessible from the internet. This moved into the Top 10 in 2021 as cloud-native architectures made it significantly more dangerous.

Practical defenses:

• Validate and sanitize all user-supplied URLs before making server-side requests: verify the scheme (allow only http/https), resolve the hostname to an IP, and block requests to private IP ranges and cloud metadata endpoints.
• Use an allowlist of permitted external domains rather than a blocklist of prohibited ones wherever possible.
• In cloud environments, assign IAM roles with minimum permissions to application hosts — even a successful SSRF against the metadata service yields fewer lateral movement options.

Frequently Asked Questions

How often is the OWASP Top 10 updated?

The OWASP Top 10 is updated roughly every three to four years. The current version is from 2021. The next revision is in progress; it is expected to reflect the growth of AI-generated code, supply chain vulnerabilities, and API-specific risks. Organizations should treat the Top 10 as a minimum baseline, not an exhaustive security standard — dedicated API security (OWASP API Security Top 10), mobile security (OWASP MASVS), and LLM security (OWASP Top 10 for LLMs) are separate resources worth incorporating for those specific contexts.

Is fixing the OWASP Top 10 enough to make my application secure?

Addressing the Top 10 eliminates the most commonly exploited vulnerability classes, but it doesn't guarantee security. Business logic vulnerabilities — flaws specific to how your application works, not generic weakness patterns — are not captured in the Top 10. A rigorous security testing program also includes application-specific threat modeling, penetration testing by external specialists, and ongoing vulnerability management. Think of OWASP Top 10 compliance as a necessary foundation, not a finish line.

How do we test our application against the OWASP Top 10?

Several approaches layer well together. Automated DAST (Dynamic Application Security Testing) tools like OWASP ZAP or Burp Suite can scan a running application for many Top 10 vulnerabilities automatically. SAST tools scan source code for vulnerability patterns. Manual penetration testing by an experienced tester will find issues that automated tools miss — particularly business logic flaws and complex authentication issues. Most mature security programs use all three layers.

Need a partner for this? Mexilet offers cybersecurity services and secure cloud & DevOps.

If you're working through these defenses and want a senior engineering perspective on your specific application's security posture, the team at Mexilet Technologies is happy to have that conversation. We offer a free initial consultation on application security architecture — no pitch, just a practical discussion of where your stack stands and what the highest-priority next steps are for your situation.