Top 50 Common Web Vulnerabilities (With Examples)
Use this page as a fast-moving reference for engineering, AppSec, and QA teams. It groups 50 common vulnerabilities by how they appear in real applications, what usually causes them, and where to start remediation.
Why this list matters
Link-worthy security content works best when it is immediately useful. This page is designed to be a practical reference that developers can bookmark, cite in internal docs, or share during reviews. It does not try to replace deep testing. Instead, it gives teams a shared vocabulary for the issues that appear most often across custom apps, APIs, admin panels, and cloud-hosted services.
1. Injection and Input Handling
These issues happen when untrusted input reaches an interpreter, parser, or dangerous API without the right controls.
- SQL Injection: attacker-controlled input changes a SQL query and exposes or alters data.
- NoSQL Injection: crafted JSON operators such as $ne or $gt bypass expected filters in document databases.
- Command Injection: user input reaches shell execution helpers and runs operating system commands.
- LDAP Injection: unescaped input changes the meaning of directory queries.
- XPath Injection: attacker input manipulates XML path queries and exposes unauthorized records.
- Template Injection: unsafely rendered templates allow expression execution on the server.
- XML External Entity Injection: weak XML parsers load external entities and leak files or enable SSRF.
- HTTP Header Injection: unsanitized data breaks header boundaries and changes response behavior.
- CSV Injection: exported spreadsheet cells beginning with formula characters execute when opened.
- Log Injection: attackers forge log lines to hide activity or mislead analysts.
2. Browser and Client-Side Risks
These flaws rely on browsers trusting unsafe content, broken isolation, or dangerous client-side behavior.
- Reflected XSS: malicious script runs because request data is echoed without output encoding.
- Stored XSS: persistent user content becomes a script execution point for later visitors.
- DOM XSS: frontend JavaScript writes attacker-controlled data into dangerous sinks such as innerHTML.
- Open Redirect: applications redirect to attacker-controlled destinations and help phishing campaigns.
- Clickjacking: sensitive pages can be framed and trick users into clicking hidden controls.
- Cross-Site Request Forgery: browsers send authenticated requests without verifying user intent.
- CORS Misconfiguration: trusted origins are too broad and expose authenticated API responses.
- PostMessage Abuse: windows trust messages without checking origin and data structure.
- Prototype Pollution: crafted keys alter object prototypes and destabilize application logic.
- Insecure File Upload Preview: image or document previews render active content in the browser.
3. Authentication, Session and Access Control
These weaknesses let attackers impersonate users, move laterally, or perform actions beyond their role.
- Broken Authentication: login flows allow credential stuffing, weak password rules, or missing MFA.
- Session Fixation: a victim keeps an attacker-chosen session identifier after login.
- Session Hijacking: stolen cookies or tokens let attackers reuse authenticated sessions.
- Insecure Password Reset: reset tokens are predictable, long-lived, or not invalidated after use.
- User Enumeration: registration or reset endpoints reveal whether an account exists.
- Broken Access Control: users change IDs, routes, or parameters to access restricted resources.
- IDOR: direct object references such as invoice IDs are exposed without server-side authorization checks.
- Privilege Escalation: ordinary users gain elevated roles through hidden parameters or flawed policy logic.
- JWT Validation Failure: APIs trust unsigned, expired, or wrongly scoped tokens.
- Missing Rate Limiting: brute-force, OTP guessing, and verification endpoint abuse remain unchecked.
4. Sensitive Data and Cryptography
These issues put confidential data at risk in transit, at rest, or during processing.
- Sensitive Data Exposure: secrets, tokens, or PII are returned in responses, logs, or client storage.
- Weak Password Hashing: legacy algorithms like SHA-1 or unsalted hashes protect credentials poorly.
- Hardcoded Secrets: API keys and database passwords live in source code or frontend bundles.
- Insufficient TLS: weak cipher suites, old protocol versions, or invalid certificate handling expose traffic.
- Insecure Deserialization: untrusted serialized objects trigger privilege changes or code execution paths.
- Padding Oracle Issues: cryptographic error differences leak information about encrypted data.
- Improper Key Management: encryption keys are stored near the data they protect.
- Unencrypted Backups: database dumps or export files are publicly reachable or weakly protected.
- Token Leakage in URLs: sensitive tokens appear in query strings and end up in logs and analytics.
- Cache Exposure: private responses are cached by shared proxies or browsers without proper directives.
5. Security Misconfiguration and Infrastructure Weaknesses
These are often the fastest wins for attackers because they come from defaults, drift, and incomplete hardening.
- Default Credentials: admin panels or services still use vendor defaults.
- Verbose Error Messages: stack traces reveal code paths, SQL details, or internal hosts.
- Directory Listing Enabled: public folders expose backups, uploads, or generated artifacts.
- Debug Mode in Production: development helpers leak secrets and internal state.
- Missing Security Headers: CSP, HSTS, frame-ancestors, and no-sniff are absent or incomplete.
- Outdated Components: vulnerable libraries and plugins stay deployed long after fixes exist.
- Exposed Admin Interfaces: dashboards or management endpoints remain reachable from the public internet.
- SSRF Exposure: backend URL fetchers can reach cloud metadata or internal services.
- Unsafe HTTP Methods: TRACE, PUT, or DELETE remain enabled without a valid business need.
- Improper Container Hardening: containers run as root with unnecessary capabilities and writable filesystems.
How to prioritize fixes
Start with the flaws that combine external reachability, easy exploitability, and high business impact. For most teams, that means injection, broken access control, weak auth, exposed secrets, and internet-facing misconfigurations first.
Then move into repeatable hardening: standardize headers, tighten session handling, remove dangerous defaults, and make dependency review part of every release. That combination turns a static list into a useful operating model.
Turn this list into a remediation backlog
Run a scan against your public application and use the findings to validate which of these classes are present in your own stack.
Run a Security Scan