Web application security: understanding the OWASP Top Ten

Why web application security demands attention

Every customer portal, e-commerce platform, internal tool, and API your business operates is a potential target. Web applications are publicly accessible by design, handle sensitive data, and are often built under time pressure - a combination that creates fertile ground for vulnerabilities.

The Open Web Application Security Project (OWASP) maintains a regularly updated list of the ten most critical web application security risks. The OWASP Top Ten is not an exhaustive catalogue of every possible vulnerability - it’s a consensus view of the risks that cause the most damage, most frequently. Treating it as a baseline is a practical starting point for any organisation that builds or consumes web applications.

The OWASP Top Ten

1. Broken access control

The risk: Users can act outside their intended permissions. A regular user accesses admin functions. A customer views another customer’s data by manipulating a URL parameter. An API endpoint intended for internal use is exposed publicly.

Mitigation:

Deny access by default - explicitly grant permissions rather than assuming them.
Enforce server-side access checks on every request. Client-side controls are trivially bypassed.
Use role-based or attribute-based access control and validate against the authenticated user’s permissions.
Log access control failures and alert on repeated violations.

2. Cryptographic failures

The risk: Sensitive data is exposed because of weak, missing, or misused cryptography. Passwords stored in plain text. Data transmitted without TLS. Encryption keys hardcoded in source code.

Mitigation:

Enforce HTTPS everywhere - there is no longer a valid reason to serve any page over plain HTTP.
Use strong, current algorithms (AES-256 for encryption, bcrypt or Argon2 for password hashing).
Never store sensitive data unnecessarily. If you don’t need it, don’t keep it.
Manage encryption keys properly - use a vault, rotate regularly, and restrict access.

3. Injection

The risk: Untrusted data is sent to an interpreter as part of a command or query. SQL injection remains the most well-known variant, but the category includes NoSQL injection, OS command injection, LDAP injection, and expression language injection.

Mitigation:

Use parameterised queries or prepared statements for all database interactions. This is the single most effective defence against SQL injection.
Validate and sanitise all input, but never rely on sanitisation alone.
Apply the principle of least privilege to database accounts - the application should not connect with admin credentials.

4. Insecure design

The risk: The application was designed without security in mind. Threat modelling was skipped. Business logic flaws allow abuse. The architecture lacks defence in depth.

Mitigation:

Incorporate threat modelling into the design phase. Before writing code, ask: what could go wrong?
Use secure design patterns: separation of concerns, input validation at boundaries, fail-safe defaults.
Establish abuse cases alongside use cases - how might an attacker misuse this feature?
Conduct design reviews with security-aware engineers.

5. Security misconfiguration

The risk: Default credentials left in place. Unnecessary features enabled. Error messages that reveal stack traces and internal paths. Cloud storage buckets open to the public. Missing security headers.

Mitigation:

Harden all environments: development, staging, and production. Use automated configuration management.
Remove or disable unused features, frameworks, and endpoints.
Implement security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security).
Conduct regular configuration reviews and use scanning tools to detect drift.

6. Vulnerable and outdated components

The risk: The application uses libraries, frameworks, or components with known vulnerabilities. The Log4Shell vulnerability in 2021 demonstrated how a single outdated library can expose millions of systems.

Mitigation:

Maintain an inventory of all components and their versions (a software bill of materials).
Monitor vulnerability databases (CVE, NVD) and subscribe to vendor advisories.
Automate dependency scanning in your CI/CD pipeline.
Update promptly. If a component is no longer maintained, find an alternative.

7. Identification and authentication failures

The risk: Weak or broken authentication allows attackers to compromise user accounts. Credential stuffing, brute force, weak password policies, missing MFA, and insecure session management all fall under this category.

Mitigation:

Enforce multi-factor authentication, especially for privileged accounts.
Implement account lockout or rate limiting after failed login attempts.
Use secure session management: random session IDs, proper expiration, and invalidation on logout.
Never expose session tokens in URLs.
Integrate with a centralised identity and access management platform where possible.

8. Software and data integrity failures

The risk: Code and data are not verified for integrity. Insecure CI/CD pipelines allow code tampering. Auto-update mechanisms download unsigned packages. Serialised data is trusted without validation.

Mitigation:

Verify the integrity of all downloaded dependencies using signatures or checksums.
Secure your CI/CD pipeline - restrict access, audit changes, and sign builds.
Avoid deserialising untrusted data. If unavoidable, validate and constrain input.

9. Security logging and monitoring failures

The risk: Breaches go undetected because logging is insufficient or nobody is watching. The average time to detect a breach globally is still over 200 days. Without adequate logging, incident response is blind.

Mitigation:

Log authentication events, access control failures, input validation failures, and application errors.
Centralise logs and monitor them actively - either with internal tooling or a security operations partner.
Ensure logs are tamper-evident and retained for an appropriate period.
Establish alerting thresholds and incident response procedures.

10. Server-side request forgery (SSRF)

The risk: The application fetches a remote resource based on user-supplied input without validating the destination. An attacker can direct the server to make requests to internal services, cloud metadata endpoints, or other systems that should not be accessible.

Mitigation:

Validate, sanitise, and whitelist all URLs provided by users.
Block requests to private IP ranges and cloud metadata endpoints from server-side code.
Use network segmentation to limit what the application server can reach.
Monitor for unusual outbound traffic patterns.

Building a secure development lifecycle

Addressing the OWASP Top Ten is not a one-time exercise. Security must be embedded in the entire development lifecycle:

Requirements - define security requirements alongside functional ones. Include authentication, authorisation, data protection, and logging.
Design - conduct threat modelling. Identify attack surfaces and design mitigations.
Development - use secure coding standards. Conduct peer reviews with security awareness.
Testing - include security testing in your QA process. Use static analysis (SAST), dynamic analysis (DAST), and manual penetration testing.
Deployment - harden configurations. Automate deployment to reduce human error.
Operations - monitor, log, and respond. Patch promptly. Review access regularly.

A web application engineering partner that understands security can help you build these practices into your team’s workflow rather than bolting them on after the fact.

Getting started

You don’t need to address all ten risks simultaneously. Start with the highest-impact items for your application:

Enable MFA and strengthen authentication.
Review access control logic - test whether users can access resources they shouldn’t.
Scan your dependencies for known vulnerabilities.
Enforce HTTPS and implement security headers.
Centralise logging and ensure someone is watching.

ITHQ builds and secures web applications for South African businesses. Our web application engineering team works alongside cybersecurity operations and cloud architecture specialists to ensure your applications are resilient by design.