cyber-101

What are key risks in web application security and their differences?

A beginner-friendly look at six common web app threats, how they differ, and how each maps to OWASP, MITRE ATT&CK, NIST, and PCI DSS.

Photo by Hal Gatewood / Unsplash

💡

This is part of an on-going series in cybersecurity foundations. Check the cyber 101 article tag index from time to time for more content.

A question I get asked from time to time is about common risks in web application security. What are the big ones, and how are they different from each other? So for today's article, I'd like to walk through some of the most common threats facing organizations today (in no particular order). Along the way, I'll also show you how each one maps to the major security frameworks.

If you're new to security, those frameworks can look like a big bowl of alphabet soup. Don't worry. Here's a quick cheat sheet for the ones I'll reference:

OWASP Top 10 - A list of the most critical security risks to web applications, updated every few years. I'll be using the 2025 edition. OWASP also keeps a separate API Security Top 10 just for APIs.
CWE - A catalog of common software weaknesses. Think of these as the underlying coding mistakes.
MITRE ATT&CK and CAPEC - Catalogs of real-world attacker behavior and attack patterns. In other words, what the bad guys actually do.
NIST SP 800-53, PCI DSS, and ISO/IEC 27001 - Frameworks that describe the security controls organizations are expected to have in place. NIST 800-53 is required for U.S. federal systems, PCI DSS applies to anyone who handles payment card data, and ISO 27001 is a widely used international standard. (All PCI DSS references here are to v4.0.1, the current version.)

Grab your beverage of choice, and let's dig in.

SQL Injection

Despite being one of the oldest web vulnerabilities around, SQL Injection (SQLi) is still incredibly effective. It happens when an application takes user input (from a search box or a login form, for example) and drops it straight into a database query without handling it safely. That gives attackers an opening to slip in their own SQL code to view, modify, or delete data.

The classic example? Typing something like ' OR '1'='1 into a login form. If the query behind it is poorly written, that little snippet can make the login check always come back "true" and let the attacker right in.

And because so many modern web applications rely on databases, a successful SQLi attack can be a really big deal.

How SQLi Maps to Major Security Frameworks

OWASP Top 10 (A05:2025 - Injection) & CWE-89: SQLi is the poster child for OWASP's Injection category. At its core, it's a failure to keep untrusted input separate from the query itself, which is exactly the problem parameterized queries solve.
MITRE ATT&CK (T1190 - Exploit Public-Facing Application): ATT&CK tracks what attackers do once SQLi gets them in the door. That can include running operating system commands (T1059), setting up persistence through stored procedures (T1505.001), and pulling data straight out of the database (T1213.006).
NIST SP 800-53 (SI-10 & AC-6) & PCI DSS (Req. 6.2.4 & 6.4.2): On the compliance side, the big themes are validating input (SI-10), using secure coding practices that prevent injection (Req. 6.2.4), giving database accounts only the permissions they need (AC-6), and putting an automated defense like a Web Application Firewall (WAF) in front of public-facing apps (Req. 6.4.2).

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) happens when a web application takes untrusted input and puts it into a web page without properly validating or encoding it first. Here's the key difference from SQLi: SQLi goes after the backend database, while XSS goes after the application's users. The malicious code (usually JavaScript) runs right inside the victim's browser.

XSS comes in a few different flavors. The three you'll hear about most often are:

Stored XSS – The malicious script gets saved on the server (in a database, comment section, forum post, etc.) and then served up to everyone who views that content.
Reflected XSS – The payload rides in on a malicious link. When the victim clicks it, the server bounces the script right back in its response, and the browser runs it.
DOM-based XSS – This one happens entirely in the browser. The page's own JavaScript grabs attacker-controlled data (like part of the URL) and writes it into the page unsafely. In some cases, the payload never even touches the server.

Whatever the flavor, the end result looks similar. Attackers can hijack sessions, steal credentials, change what the page displays, or take actions on the victim's behalf.

How XSS Maps to Major Security Frameworks

OWASP Top 10 (A05:2025 – Injection) & CWE-79: XSS also lives in OWASP's Injection category. It's the same family of mistake as SQLi: untrusted input reaches a parser (in this case, the browser) without being neutralized first.
MITRE ATT&CK (T1189, T1059.007, & T1539) & CAPEC-63: ATT&CK lists XSS as one of the ways attackers pull off a Drive-by Compromise (T1189). From there, the injected script runs as JavaScript in the victim's browser (T1059.007) and can be used to steal session cookies (T1539) and take over accounts. CAPEC-63 is CAPEC's entry for XSS itself.
NIST SP 800-53 (SI-10) & PCI DSS (Req. 6.2.4 & 6.4.3): Defenses start with input validation (SI-10) and secure coding practices that guard against common attacks like XSS (Req. 6.2.4). For payment pages specifically, PCI also requires that every script running in the customer's browser is authorized, integrity-checked, and inventoried (Req. 6.4.3). Content Security Policy (CSP) and HttpOnly cookie flags are popular ways to back all of this up.

Zero-Day Vulnerabilities

This one gets a lot of media attention (and for good reason). A zero-day is a flaw in a web application, server, framework, or third-party library that attackers discover and exploit before the vendor or developer even knows it exists. The name says it all: the vendor has had zero days to fix it.

Here's what makes zero-days different from everything else on this list: "zero-day" describes timing, not a type of bug. A zero-day could be a SQL injection flaw, an access control bug, or something else entirely. What makes it so dangerous is that when the attack begins, there's no CVE identifier, no vendor patch, and no traditional signature to catch it.

That means organizations can't count on patching to save them, at least not right away. Instead, they need architectural containment (limiting how far an attacker can get) and behavioral detection (spotting suspicious activity as it happens). This is where layered defense, also known as defense-in-depth, really earns its keep (but that's a topic for another day).

How Zero-Day Vulnerabilities Map to Major Security Frameworks

OWASP Top 10 (A03:2025 - Software Supply Chain Failures & A06:2025 - Insecure Design): Lots of zero-days hide in third-party libraries and dependencies, which is exactly what the Supply Chain Failures category covers. Insecure Design is the other half of the story: smart design choices like least privilege and sandboxing limit the blast radius when an unknown flaw gets exploited.
MITRE ATT&CK (T1587.004 / T1588.005 - Exploits & T1190 - Exploit Public-Facing Application): ATT&CK tracks how adversaries develop their own exploits (T1587.004) or buy them (T1588.005) ahead of an attack, then use them to break through the web perimeter (T1190). Here's the really useful part for defenders: much of ATT&CK focuses on what attackers do after they get in, like spawning unexpected shell processes (T1059) or escalating privileges (T1068). So even without a known signature, a SOC team can still catch a zero-day intrusion by its behavior. Nifty, right?
NIST SP 800-53 (SI-2 & SC-39) & PCI DSS (Req. 6.3 & 6.4.2): Two things matter here. First, you need to know what you're running so you can patch fast once a fix drops. PCI requires an inventory of your custom software and the third-party components inside it (Req. 6.3.2), which is where a Software Bill of Materials (SBOM) comes in handy. PCI also requires patches for critical vulnerabilities within one month of release (Req. 6.3.3), while NIST's flaw remediation control (SI-2) lets organizations set their own timelines. Second, you need to contain what you can't patch yet, using process isolation (SC-39) and an automated defense like a WAF (Req. 6.4.2) that can "virtually patch" the gap.

Bot Attacks

Bot attacks happen when adversaries use automated scripts or botnets (networks of compromised devices) to hammer web applications and APIs at machine speed. Here's the twist: instead of exploiting a coding flaw, malicious bots usually abuse legitimate features, just at a scale no human could match. A login page might work exactly as designed... right up until a bot hits it tens of thousands of times an hour.

Common examples include:

Credential stuffing (trying username/password pairs leaked from other breaches)
Automated password brute-forcing
Carding (testing stolen credit card numbers)
Content scraping
Inventory hoarding (tying up limited stock so real customers can't buy it)
Application-layer Distributed Denial of Service (DDoS) floods

What makes bots tricky is how good they've gotten at blending in. Modern bots mimic real browser fingerprints and route their traffic through rotating residential proxies, so they look like regular folks browsing from home. That's why simple IP blocklists don't cut it anymore. Defenders lean on behavioral rate-limiting, telemetry analysis, and challenge mechanisms instead.

How Bot Attacks Map to Major Security Frameworks

OWASP Automated Threats (OAT), OWASP Top 10 (A07:2025), OWASP API Security Top 10 (API6:2023), & CWE-307: OWASP actually has a whole project dedicated to this: the Automated Threats to Web Applications catalog. It has entries for most of the attacks above, like OAT-008 Credential Stuffing, OAT-007 Credential Cracking (brute-forcing), OAT-001 Carding, OAT-011 Scraping, and OAT-021 Denial of Inventory (inventory hoarding). Missing rate limits and anti-automation controls also map to A07:2025 (Authentication Failures), API6:2023 (Unrestricted Access to Sensitive Business Flows), and CWE-307 (Improper Restriction of Excessive Authentication Attempts). OWASP's guidance for A07 also recommends multi-factor authentication (MFA) to blunt credential stuffing and brute-force attacks.
MITRE ATT&CK (T1583.005 / T1584.005 - Botnet, T1110.004 - Credential Stuffing, & T1499 - Endpoint Denial of Service): ATT&CK tracks how adversaries rent a botnet (T1583.005) or build their own by compromising devices (T1584.005). From there, they can automate account takeovers with breached credentials (T1110.004) or overwhelm web apps with Layer 7 request floods (T1499).
NIST SP 800-53 (AC-7 & SC-5) & PCI DSS (Req. 6.4.2 & 8.3.4): The controls here focus on limiting failed login attempts (AC-7), protecting against denial of service (SC-5), and automatically detecting and blocking web attacks (Req. 6.4.2). PCI also requires account lockouts after repeated failed logins (Req. 8.3.4), though that one applies to employee and admin accounts rather than your customers.

DDoS Attacks

This is probably one of the most well-known threats out there. In a Distributed Denial of Service (DDoS) attack, adversaries flood a web application, API, or the network underneath it with so much traffic, from so many different sources (usually botnets of compromised devices), that legitimate users can't get through. Think of it like a mob crowding the front door of a store so the real customers can't get in.

DDoS attacks generally fall into two buckets:

Network/transport-layer floods (layers 3 and 4) – These are the brute-force attacks. They try to saturate bandwidth or fill up connection tables so there's no room left for real traffic.
Application-layer attacks (layer 7) – These are sneakier. They send requests that look perfectly legitimate but are designed to chew through expensive server resources like CPU, memory, or database connections.

So how is this different from a bot attack? There's definitely some overlap (that's why application-layer DDoS showed up in the bot list too). The difference is the goal. Most bot attacks want to take something from your app, like accounts, data, or inventory. A DDoS attack just wants your app to go down.

How DDoS Attacks Map to Major Security Frameworks

OWASP API Security Top 10 (API4:2023 - Unrestricted Resource Consumption) & CWE-400: For application-layer DoS, the underlying weakness is CWE-400 (Uncontrolled Resource Consumption). OWASP's API list covers it under API4:2023, which focuses on missing guardrails like rate limits, query timeouts, maximum payload sizes, and pagination. (Fun fact: resource exhaustion just barely missed the cut for the main OWASP Top 10:2025. It shows up as an honorable mention called "Lack of Application Resilience.")
MITRE ATT&CK (T1498 & T1499) & CAPEC-469: ATT&CK files DDoS under the Impact tactic (TA0040) and splits it two ways. Network Denial of Service (T1498) covers saturating bandwidth with direct floods or reflection amplification (T1498.001, T1498.002). Endpoint Denial of Service (T1499) covers knocking web servers over with HTTP floods or heavy application requests (T1499.002, T1499.003). CAPEC-469 covers HTTP-based DoS specifically.
NIST SP 800-53 (SC-5), ISO/IEC 27001:2022 (A.8.6 - Capacity Management), & PCI DSS (Req. 6.4.2): The theme here is having enough headroom and the right filters in place. SC-5 calls for denial-of-service protections, A.8.6 covers capacity planning, and Req. 6.4.2 requires an automated solution in front of public-facing web apps. In practice, that usually means upstream traffic scrubbing, Content Delivery Networks (CDNs), rate limiting, and edge WAFs that soak up the flood before it reaches your servers.

Broken Access Control (and IDOR)

Broken Access Control happens when a web application doesn't properly enforce what users (logged in or not) are allowed to do and see. Here's an easy way to keep it straight: authentication answers "Who are you?" while access control answers "What are you allowed to touch?"

A classic example is an Insecure Direct Object Reference (IDOR). An attacker simply changes an account or order number in a URL or API call (say, from /api/orders/1042 to /api/orders/1043), and the server happily hands back another customer's private data without checking who it belongs to.

That example shows what makes this category different from injection: there's no malicious code involved at all. The attacker is just asking for something they shouldn't have, and the app forgets to say no. Left unchecked, broken access control can lead to mass data exposure and privilege escalation. That escalation can be horizontal (accessing other users' data, like the IDOR example above) or vertical (a standard user gaining administrator rights).

How Broken Access Control Maps to Major Security Frameworks

OWASP Top 10 (A01:2025 - Broken Access Control), OWASP API Security Top 10 (API1:2023 - BOLA), & CWE-284 / CWE-639: This one holds the #1 spot on both OWASP lists. On the API side, it's called Broken Object Level Authorization (BOLA), which is essentially IDOR for APIs. It maps to improper access control (CWE-284) and authorization bypass through user-controlled keys (CWE-639), which is IDOR in a nutshell.
MITRE ATT&CK (T1078 - Valid Accounts & T1213 - Data from Information Repositories) & CAPEC-180: ATT&CK's coverage is a bit thinner here. It mostly tracks attacker behavior on systems and networks, and it points to the OWASP Top 10 and CWE Top 25 for the details of web vulnerabilities. The closest fits are attackers working from a legitimate account or session (T1078) and harvesting records they shouldn't have access to (T1213). CAPEC-180 (Exploiting Incorrectly Configured Access Control Security Levels) does a better job describing the attack itself.
NIST SP 800-53 (AC-3 & AC-6) & PCI DSS (Req. 7.2, 7.3.3, & 6.2.4): The fix is simple in concept (if not always in practice): check authorization on the server for every single request (AC-3), give users only the access they actually need (AC-6 / Req. 7.2), and deny everything by default unless it's explicitly allowed (Req. 7.3.3). PCI also expects developers to guard against access control attacks in their custom code (Req. 6.2.4).

So, How Do These Differ?

Phew! We covered a lot here. If you're trying to keep these straight, here's the short version:

SQL Injection goes after the database by sneaking code into queries.
XSS goes after your users by sneaking code into the pages their browsers run.
Zero-days aren't a type of bug at all. They're about timing: any flaw that gets exploited before a fix exists.
Bot attacks abuse features that work exactly as designed, just at machine scale, usually to steal something (accounts, data, inventory).
DDoS attacks also rely on scale, but the goal is to knock the service offline.
Broken access control doesn't involve malicious code at all. It's the app failing to check whether you're allowed to do what you're asking.

If there's one big takeaway, it's that no single control covers everything on this list. Solid input handling, smart rate limiting, strict authorization checks, and layered defenses all work together, and each one closes a different door.

For additional information, check out these resources: