{{#include ../banners/hacktricks-training.md}}
In every Web Pentest, there are several hidden and obvious places that might be vulnerable. This post is meant to be a checklist to confirm that you have searched for vulnerabilities in all the possible places.
Tip
Nowadays web applications usually uses some kind of intermediary proxies, those may be (ab)used to exploit vulnerabilities. These vulnerabilities need a vulnerable proxy to be in place, but they usually also need some extra vulnerability in the backend.
- Abusing hop-by-hop headers
- Cache Poisoning/Cache Deception
- HTTP Connection Contamination
- HTTP Connection Request Smuggling
- HTTP Request Smuggling
- HTTP Response Smuggling / Desync
- H2C Smuggling
- Server Side Inclusion/Edge Side Inclusion
- Uncovering Cloudflare
- XSLT Server Side Injection
- Proxy / WAF Protections Bypass
Tip
Most of the web applications will allow users to input some data that will be processed later.
Depending on the structure of the data the server is expecting some vulnerabilities may or may not apply.
If the introduced data may somehow be reflected in the response, the page might be vulnerable to several issues.
- Client Side Path Traversal
- Client Side Template Injection
- Command Injection
- CRLF
- Dangling Markup
- File Inclusion/Path Traversal
- Open Redirect
- Prototype Pollution to XSS
- Server Side Inclusion/Edge Side Inclusion
- Server Side Request Forgery
- Server Side Template Injection
- Reverse Tab Nabbing
- XSLT Server Side Injection
- XSS
- XSSI
- XS-Search
Some of the mentioned vulnerabilities require special conditions, others just require the content to be reflected. You can find some interesting polygloths to test quickly the vulnerabilities in:
{{#ref}} pocs-and-polygloths-cheatsheet/ {{#endref}}
If the functionality may be used to search some kind of data inside the backend, maybe you can (ab)use it to search arbitrary data.
- File Inclusion/Path Traversal
- NoSQL Injection
- LDAP Injection
- ReDoS
- SQL Injection
- ORM Injection
- RSQL Injection
- XPATH Injection
When a websocket posts a message or a form allowing users to perform actions vulnerabilities may arise.
- Cross Site Request Forgery
- Cross-site WebSocket hijacking (CSWSH)
- Phone Number Injections
- PostMessage Vulnerabilities
WebSocket upgrades automatically forward cookies and do not block ws://127.0.0.1, so any web origin can drive desktop IPC endpoints that skip Origin validation. When you spot a launcher exposing a JSON-RPC-like API through a local agent:
- Observe emitted frames to clone the
type/name/argstuples required by each method. - Bruteforce the listening port directly from the browser (Chromium will handle ~16k failed upgrades) until a loopback socket answers with the protocol banner—Firefox tends to crash quickly under the same load.
- Chain a create → privileged action pair: e.g., invoke a
create*method that returns a GUID and immediately call the corresponding*Launch*method with attacker-controlled payloads.
If you can pass arbitrary JVM flags (such as AdditionalJavaArguments), force an error with -XX:MaxMetaspaceSize=<tiny> and attach -XX:OnOutOfMemoryError="<cmd>" to run OS commands without touching application logic. See WebSocket attacks for a walk-through.
Depending on the HTTP headers given by the web server some vulnerabilities might be present.
- Clickjacking
- Iframe Traps / Click Isolation
- Content Security Policy bypass
- Cookies Hacking
- CORS - Misconfigurations & Bypass
There are several specific functionalities where some workarounds might be useful to bypass them
- 2FA/OTP Bypass
- Bypass Payment Process
- Captcha Bypass
- Account Takeover Playbooks
- Login Bypass
- Race Condition
- Rate Limit Bypass
- Reset Forgotten Password Bypass
- Registration Vulnerabilities
Some functionalities will require the data to be structured in a very specific format (like a language serialized object or XML). Therefore, it's easier to identify if the application might be vulnerable as it needs to be processing that kind of data.
Some specific functionalities may be also vulnerable if a specific format of the input is used (like Email Header Injections).
- Deserialization
- Email Header Injection
- JWT Vulnerabilities
- JSON / XML / YAML Hacking
- XML External Entity
- GraphQL Attacks
- gRPC-Web Attacks
- SOAP/JAX-WS ThreadLocal Auth Bypass
Functionalities that allow uploading files might be vulnerable to several issues.
Functionalities that generate files including user input might execute unexpected code.
Users that open files uploaded by users or automatically generated including user input might be compromised.
These vulnerabilities might help to exploit other vulnerabilities.
- Domain/Subdomain takeover
- IDOR
- Mass Assignment (CWE-915)
- Parameter Pollution
- Unicode Normalization vulnerability
Misconfigurations in the edge stack often unlock more impactful bugs in the application layer.
- Apache
- Nginx
- IIS
- Tomcat
- Spring Actuators
- PUT Method / WebDAV
- Special HTTP Headers
- WSGI Deployment
- Werkzeug Debug Exposure
Framework-specific primitives frequently expose gadgets, dangerous defaults, or framework-owned endpoints.
High-surface products often ship with known exploits, weak plugins, or privileged admin endpoints.
- WordPress
- Joomla
- Drupal
- Moodle
- Prestashop
- Atlassian Jira
- Grafana
- Rocket.Chat
- Zabbix
- Microsoft SharePoint
- Sitecore
Server-side helpers and third-party integrations can expose file parsing or storage-layer weaknesses.
- Web API Pentesting
- Storage Buckets & Firebase
- Imagemagick Security
- Artifactory & Package Registries
- Code Review Tooling
Attacks that target build pipelines or predictable identifiers can become the initial foothold before exploiting traditional bugs.
Modern applications extend into browsers, wallets, and automation pipelines—keep these vectors in scope.
{{#include ../banners/hacktricks-training.md}}