This glossary explains the most common web application vulnerabilities and the security terms that go with them, in plain language. It is built for people starting from zero, so each entry is short and concrete. Where we have a deeper post, the term links to it. Skim it, bookmark it, or read it top to bottom.
The entries are grouped into core concepts, access control, injection and input, logic and API flaws, and the ways people test for all of these. If you only read one section, read common web application vulnerabilities first.
Core concepts
- Vulnerability. A weakness in an application that lets someone do something they should not be able to do, like read another user’s data or run their own code on the server.
- Exploit. The specific steps or request that turns a vulnerability into real impact. A vulnerability is the open window; the exploit is climbing through it.
- Threat. Anyone or anything that could act against the app, from a bored attacker to an automated bot scanning the whole internet.
- Attack surface. Every place an attacker can touch the app: pages, forms, API endpoints, file uploads, headers, and parameters. The bigger the surface, the more there is to get wrong.
- Payload. The piece of input that triggers the bug, for example a snippet of script or a crafted value in a URL parameter.
- Proof of concept. A safe demonstration that a bug is real, without causing damage. It is the difference between “this might be exploitable” and “here is the proof.”
- False positive. A finding a tool reports that is not actually exploitable. Too many of these waste a team’s time and train them to ignore alerts.
- CVE. A public identifier for a known vulnerability in a specific piece of software, like CVE 2024 12345. It lets everyone refer to the same issue.
- CVSS. A scoring system from 0 to 10 that rates how severe a vulnerability is. Higher means worse, but context still matters more than the number.
- Zero day. A vulnerability that is being exploited before the vendor has a fix available. Defenders have zero days of warning.
Access control
Access control bugs are about who is allowed to do what. They are some of the highest impact issues because they often expose other users’ data directly. See access control vulnerabilities for the full picture.
- Authentication. Proving who you are, usually with a password or a login token. See authentication vs authorization.
- Authorization. Deciding what you are allowed to do once you are logged in. Many breaches come from getting this step wrong.
- Broken access control. When the app fails to check that a user is allowed to perform an action, so a normal user can reach admin pages or other people’s records.
- IDOR. Insecure direct object reference. Changing an id in a URL like
/invoice/123to/invoice/124and seeing data that is not yours. See the IDOR and BOLA entry. - BOLA. Broken object level authorization. The API version of IDOR, and the most common serious API flaw. The endpoint returns an object without checking it belongs to the caller.
- Privilege escalation. Gaining rights you should not have. See privilege escalation.
- Horizontal escalation. Acting as another user at the same level, for example reading a peer’s messages.
- Vertical escalation. Jumping to a higher level, for example a normal user gaining admin powers.
- Session. The server’s memory that you are logged in, tracked by a cookie or token. Steal the session and you become that user.
- JWT. JSON web token. A signed token that carries login claims. Weak signing or trusting unverified claims turns it into an access control bug.
Injection and input
Injection happens when input is treated as a command instead of plain data. The app mixes attacker text into a query, a page, or a shell, and the attacker’s text takes over.
- Injection. The general class where untrusted input changes the meaning of a command the app runs.
- SQL injection. Injecting database query syntax to read or change data the app never meant to expose. See SQL injection.
- Cross site scripting. XSS. Injecting script that runs in another user’s browser, often to steal sessions. See cross site scripting.
- Stored XSS. The script is saved by the app, for example in a comment, and runs for every visitor who views it.
- Reflected XSS. The script comes back in the response to a single crafted request, usually delivered through a link.
- DOM XSS. The bug lives in client side JavaScript that writes attacker input into the page without cleaning it.
- Command injection. Getting the server to run your operating system commands. See command injection.
- SSTI. Server side template injection. Input is rendered as a template expression, which can lead to running code on the server.
- Path traversal. Using sequences like
../to read files outside the intended folder, such as configuration or password files. - SSRF. Server side request forgery. Tricking the server into making requests for you, often to reach internal systems a user cannot touch directly.
- XXE. XML external entity. Abusing XML parsing to read local files or make the server send requests.
- CSRF. Cross site request forgery. Tricking a logged in user’s browser into sending an action they did not intend, like changing their email.
- Open redirect. A redirect that sends users to any URL an attacker supplies, useful for convincing phishing links.
Logic and API flaws
These bugs are not about malformed input. The request is valid; the app’s rules are wrong. They are hard for scanners to catch because nothing looks broken on the surface.
- Business logic vulnerability. A flaw in the app’s rules, like applying a discount twice or skipping a payment step. See business logic vulnerabilities.
- Mass assignment. Sending extra fields in a request, like
role=admin, that the app blindly saves because it trusts the whole object. - Broken function level authorization. An admin only action that is reachable by anyone who knows the endpoint, because the function itself never checks the role.
- Rate limiting. A control that caps how often an action can run. Missing it enables brute force, scraping, and abuse.
- Race condition. Sending requests at the same moment to slip between two steps, for example redeeming one gift code twice before the balance updates.
How these get found and tested
Finding web application vulnerabilities is its own discipline. Different methods catch different things, and none catches everything. For the bigger picture see how hackers find vulnerabilities and web application security.
- Penetration testing. A skilled person tries to break the app on purpose and reports what worked.
- Automated penetration testing. Software that does much of that work continuously. See automated penetration testing.
- Vulnerability scanner. A tool that checks an app against a list of known issues and patterns. Fast and broad, but prone to false positives and blind to logic bugs.
- SAST. Static analysis. Reads the source code without running it. See SAST vs DAST vs IAST.
- DAST. Dynamic analysis. Tests the running app from the outside, the way an attacker sees it.
- IAST. Interactive analysis. Watches the app from the inside while it runs to spot issues with more context.
- Fuzzing. Throwing large amounts of malformed or random input at the app to see what crashes or misbehaves.
- Verification. Proving a finding is real with concrete evidence before reporting it, so the output is signal and not a pile of maybes.
See the ideas in action
Definitions only go so far. Two teardowns walk through how these pieces combine in a realistic app: an IDOR that exposes user data and chaining small bugs into a real breach.
The highest impact bugs rarely come from one exotic payload. They come from understanding how an app is meant to work, then noticing where that logic quietly breaks.
That is exactly the kind of reasoning an autonomous researcher that tests an app’s assumptions is built for. It learns how the app works, forms ideas about where it breaks, runs experiments, and proves a finding before reporting it. If that approach interests you, read more about UnboundCompute.