OWASP Top 10 Explained with Practical Examples

What is the OWASP Top 10?

The OWASP Top 10 is an awareness document describing major security risks in web applications. It helps developers, testers and security teams recognise common weaknesses, understand their impact and build appropriate controls.

OWASP stands for the Open Worldwide Application Security Project. This guide uses the OWASP Top 10:2021 categories, which remain a widely used reference at the time of writing. They are risk categories rather than a list of ten individual vulnerabilities.

A simple application path can be visualised as:

User browser
    |
    | HTTPS request
    v
Reverse proxy or load balancer
    |
    v
Web application -----> Authentication service
    |
    +-----------------> Database
    |
    +-----------------> Internal APIs and cloud services

A weakness can appear at any point. Access control may fail in the application, encryption may be weak in transit, an outdated library may run on the server, or monitoring may fail to detect repeated attacks.

Only test systems that you own or have written permission to assess. The examples below should be reproduced in an isolated lab using applications designed for security practice.

What are the ten OWASP security risks?

The list covers access control, cryptography, injection, application design, configuration, software components, authentication, software integrity, monitoring and server-side request forgery. Several individual findings can belong to the same category.

How does A01: Broken Access Control work?

Broken access control occurs when a user can perform an action or access data outside their permissions. The server must enforce authorisation for every protected request; hiding a button in the browser is not a security control.

Consider an invoice endpoint:

GET /api/invoices/1058
Cookie: session=valid-user-session

If changing 1058 to 1059 returns another customer's invoice, the application has an insecure direct object reference, commonly called IDOR. The user is authenticated, but the application has not verified ownership of the requested object.

A safe server-side pattern checks both the identifier and the authenticated owner:

SELECT id, total, status
FROM invoices
WHERE id = ? AND customer_id = ?;

Use deny-by-default rules, centralised authorisation checks and unpredictable identifiers as defence in depth. Random identifiers do not replace permission checks. Also verify that normal users cannot call administrator APIs directly.

How does A02: Cryptographic Failures expose data?

Cryptographic failures occur when sensitive information is insufficiently protected at rest or in transit. Common causes include plaintext traffic, weak password storage, exposed encryption keys and failure to validate TLS certificates.

For example, an application may send credentials over HTTP before redirecting users to HTTPS. The redirect happens too late because the original request has already crossed the network.

Inspect a lab server's TLS response with:

curl -I https://localhost:8443/
openssl s_client -connect localhost:8443 -servername localhost

In the OpenSSL output, review the certificate chain, expiry date, negotiated protocol and verification result. A local self-signed certificate may show a verification error in a lab, but production clients should receive a certificate chained to a trusted authority.

Passwords should be hashed with a password-specific algorithm such as Argon2id, bcrypt or scrypt, using appropriate parameters and unique salts. Do not store passwords with reversible encryption or fast hashes such as unsalted SHA-256.

How does A03: Injection happen?

Injection happens when untrusted data is interpreted as part of a command or query. SQL injection is well known, but the category also includes operating-system command, LDAP and other interpreter-based injection flaws.

This pattern is unsafe because input is joined directly into SQL:

query = "SELECT * FROM users WHERE email = '" + email + "'"

An attacker may supply characters that change the intended query structure. The correct defence is a parameterised query:

cursor.execute(
    'SELECT id, email FROM users WHERE email = %s',
    (email,)
)

Parameterisation keeps data separate from SQL instructions. Input validation is still useful for business rules, but escaping alone is easy to apply incorrectly.

When testing an authorised lab, intercept a normal request, change one parameter at a time and compare status codes, response lengths and server logs. The guide to using Burp Suite safely for intercepting and repeating requests explains that workflow without relying on uncontrolled scanning.

What makes A04: Insecure Design different?

Insecure design means the application's intended workflow lacks necessary security controls. A perfectly coded implementation can still be unsafe if the design permits unlimited sensitive actions or trusts an invalid business assumption.

Imagine a password-reset flow that sends a six-digit code but allows unlimited attempts. The code may be generated and compared correctly, yet the design does not control automated guessing.

Useful design controls include:

• Rate limits per account, source and device context
• Short-lived, single-use reset tokens
• Secure account recovery procedures
• Reauthentication before sensitive changes
• Threat modelling before implementation
• Abuse cases alongside normal user stories

A diagram-in-words for threat modelling is:

Asset: customer account
  -> Entry point: password-reset form
  -> Trust boundary: internet to application
  -> Threat: repeated code guessing
  -> Control: rate limit + expiry + alerting
  -> Verification: automated negative tests

How does A05: Security Misconfiguration occur?

Security misconfiguration occurs when systems are deployed with unsafe settings, unnecessary features or incomplete hardening. Examples include default credentials, public administration interfaces, verbose errors, directory listing and missing security headers.

Check response headers on a local lab application:

curl -s -D - -o /dev/null http://127.0.0.1:8080/

The command prints headers and discards the response body. Depending on the application, review controls such as Content-Security-Policy, X-Content-Type-Options and Strict-Transport-Security; HSTS should only be served over HTTPS.

Configuration should be version controlled, reviewed and applied consistently across development, testing and production. Remove sample applications, disable debugging, restrict management interfaces and avoid exposing stack traces to users.

Why is A06: Vulnerable and Outdated Components dangerous?

Applications inherit risk from frameworks, libraries, container images, operating systems and other dependencies. A component becomes especially dangerous when its version is unknown, unsupported or affected by a relevant known vulnerability.

For a Node.js project in a disposable lab, start with:

npm audit
npm outdated

For installed Debian or Ubuntu packages, list packages that can be upgraded:

apt list --upgradable

An audit finding does not automatically prove exploitability. Confirm the installed version, whether the affected function is reachable, the vendor advisory and whether the proposed update introduces breaking changes.

Maintain a software inventory or software bill of materials, monitor advisories and define an update process. Test patches in a staging environment rather than applying major dependency changes blindly to production.

What is A07: Identification and Authentication Failures?

This category covers weaknesses in login, identity verification and session management. Examples include weak recovery processes, missing multi-factor authentication for sensitive access, predictable session identifiers and sessions that remain active after logout.

Suppose a user changes a compromised password, but existing sessions on other devices continue to work indefinitely. The application should provide a way to revoke sessions and should invalidate them after important account-security events where appropriate.

Authentication testing should verify:

• Generic error messages that do not reveal whether an account exists
• Rate limiting and detection of repeated failures
• Secure cookie flags such as Secure, HttpOnly and suitable SameSite settings
• Session identifier rotation after login or privilege changes
• Server-side logout and session revocation
• Multi-factor authentication for high-risk operations

Authentication proves who the user is. Authorisation determines what that user may do; confusing the two often causes A01 findings.

How does A08: Software and Data Integrity Failures happen?

Software and data integrity failures arise when an application trusts code, updates, build artefacts or serialised data without verifying its integrity. The category includes insecure update processes, unsafe deserialisation and compromised CI/CD dependencies.

For example, a deployment pipeline downloads a script from an external location and executes it without pinning a version or checking a signature or checksum. If that source changes, unreviewed code enters the build.

A checksum comparison can detect accidental or malicious file modification when the expected hash comes from a trusted channel:

sha256sum application.tar.gz
sha256sum -c application.tar.gz.sha256

Use signed artefacts, protected branches, reviewed pipeline changes, least-privilege build identities and controlled dependency repositories. A checksum served beside a file on the same compromised server does not establish trust by itself.

Why is A09: Security Logging and Monitoring Failures important?

Security controls cannot support investigation or timely response if important events are missing from logs. Applications should record useful security events and send actionable alerts without storing passwords, tokens or other unnecessary secrets.

A login record might contain:

2026-10-05T10:14:22Z event=login_failed user_id=1842
source_ip=192.0.2.25 request_id=7fd31 reason=bad_password

Useful events include repeated authentication failures, access-control denials, administrator actions, account recovery and changes to security settings. Protect logs from tampering, synchronise system time and retain records according to operational and legal requirements.

Centralised platforms correlate activity across applications, hosts and network controls. See how SIEM platforms detect threats from logs for a practical explanation of ingestion, correlation and alert investigation.

How does A10: Server-Side Request Forgery work?

Server-side request forgery, or SSRF, occurs when an application fetches a user-controlled destination without sufficient restrictions. The server may reach internal services that are inaccessible directly from the user's network.

A typical feature imports an image from a URL:

User -> POST /fetch-image with a URL
Application server -> Requests supplied destination
Destination -> Could be public, loopback or internal

Blocking only the text localhost is insufficient because destinations can be represented in different ways or can change through DNS. Prefer a strict allowlist of required schemes, hosts and ports; resolve and validate addresses; block private, loopback, link-local and other reserved ranges; and control outbound network access.

Redirects must also be checked because an allowed URL could redirect to a prohibited destination. In cloud environments, protect instance metadata services using the cloud provider's available controls and ensure application identities have minimal permissions.

How can you test the OWASP Top 10 in a safe lab?

Use a deliberately vulnerable application in an isolated environment and test one risk at a time. Combine browser developer tools, an intercepting proxy, application logs and source-code review rather than depending only on automated scanner results.

A practical workflow is:

1. Define written scope, target address and permitted techniques.
2. Record a normal request and expected response.
3. Identify inputs, identities and trust boundaries.
4. Change one variable at a time.
5. Compare the response, server log and database effect.
6. Reproduce the issue with the smallest safe proof.
7. Apply a control and run the same test again.
8. Document evidence, impact and remediation.

For local HTTP checks, verbose curl output helps separate connection, TLS and application problems:

curl -vk https://127.0.0.1:8443/health

-v displays request and response details. -k disables certificate verification and should be used only for a known self-signed lab certificate, not as a production fix.

Learners who want guided web testing, reporting and remediation practice can explore the Ethical Hacking course.

How do you troubleshoot confusing test results?

Start by confirming connectivity, authentication state and the exact request before concluding that a vulnerability exists. Proxies, caches, redirects, web application firewalls and expired sessions can create misleading results.

Do not treat a status code alone as proof. A strong finding includes a repeatable request, observed impact, relevant logs, affected component and a remediation that succeeds during retesting.

Summary

The OWASP Top 10 explained through practical examples shows that web security is broader than finding injection flaws. Secure applications need correct access control, protected data, resilient design, hardened configuration, managed dependencies, reliable identity controls, trusted software delivery and useful monitoring.

The best learning method is to reproduce each issue in an authorised lab, observe both client and server behaviour, apply a fix and retest it. To enquire about practical lab sessions and upcoming batch details, visit the Ethical Hacking course.

Reviewed by Network Rhinos cybersecurity trainers.