Vulnerability Testing — A Practical Guide to the Core Bug Classes and Advanced Techniques

Once reconnaissance is complete, the application has been mapped, and interesting endpoints have been flagged in Burp Suite, the real work of a bug bounty engagement begins: systematic vulnerability testing. This phase is where hypotheses generated during recon and manual exploration are either confirmed or discarded. It rewards patience and method over speed, since scanners can point at anomalies but cannot judge real-world impact — that judgment call is what separates a valid, well-paid report from an informational note.

Below is a professional overview of the vulnerability classes that make up this phase, along with the reasoning a tester applies to each one.

Cross-Site Scripting (XSS)

XSS remains one of the most commonly reported web vulnerabilities because it can surface almost anywhere user input is later rendered in a browser. Testers generally divide it into four categories: stored XSS, where a malicious payload is saved server-side and served to other users later (support tickets, display names, and comments are classic vectors); reflected XSS, where input from a URL or form is echoed back in the same response; DOM-based XSS, which never touches the server and instead exploits unsafe client-side JavaScript sinks such as innerHTML or eval(); and blind XSS, where a payload fires in a context the tester cannot directly observe — an admin dashboard or a backend report — and is confirmed via an out-of-band callback service.

Effective testing means probing every input field, not just the obvious search boxes, and paying attention to fields visible only to privileged users, since XSS that executes in an administrator’s session carries substantially higher impact than XSS confined to the reporter’s own account.

Common test markers: a simple alert-box or unique-string payload (e.g. "><svg onload=alert(document.domain)>) confirms execution and identifies which application it fired in when multiple targets are tested at once.

Advanced techniques:

• Filter-bypass mutation. When a WAF or sanitizer blocks the obvious <script> tag, testers rotate through alternative event handlers and tag combinations — <img src=x onerror=...>, <svg onload=...>, or malformed tags that browsers still parse (<img/src=x/onerror=...>) — to find gaps in the filter's tag or attribute allow-list rather than its keyword list.
• Mutation XSS (mXSS). Payloads are crafted so that the raw, sanitized-looking markup is one thing, but the browser’s HTML parser silently “corrects” it into something dangerous once it’s re-serialized by innerHTML. This defeats sanitizers that check input before parsing rather than after.
• DOM clobbering. Rather than injecting script, the attacker injects HTML elements whose id or name attributes overwrite global JavaScript variables the page's own code relies on, redirecting logic without ever triggering a script-tag-based detector.
• CSP bypass via JSONP/allow-listed endpoints. When a Content-Security-Policy is present, testers look for a script-hosting endpoint already on the site’s allow-list (an old JSONP callback, an open redirect on a trusted CDN subdomain) that can be abused to load attacker-controlled script within the policy’s rules.
• Polyglot payloads. A single string engineered to execute as valid script in multiple contexts (HTML body, attribute, JavaScript string, URL) simultaneously — useful when the injection context isn’t known in advance and only one test request is practical, such as in blind or stored scenarios.

Server-Side Template Injection (SSTI)

SSTI occurs when user input is inserted into a server-side template engine without proper sandboxing, allowing an attacker to manipulate the template syntax itself rather than just the data it renders. Because different frameworks use different template delimiters, testers typically probe with a handful of small mathematical expressions and observe whether the result is evaluated — confirming both the vulnerability and the underlying engine. SSTI is treated as high-severity by default because, depending on the framework, it frequently provides a path to remote code execution.

Advanced techniques:

• Engine fingerprinting via differential math. Because delimiters and evaluation rules differ by engine (Jinja2/Twig use {{ }}, Freemarker uses ${ }, Velocity uses #set), testers submit a small set of framework-specific probes side by side and compare which one evaluates versus which one is reflected literally, quickly narrowing down the exact engine in use.
• Sandbox-escape chaining. Many modern template engines run in a restricted sandbox that blocks direct OS calls. Advanced testing walks the object graph reachable from the template context — enumerating built-in object attributes and base classes — to find an indirect path back to an unrestricted function, a technique widely documented for Python-based engines via their object introspection model.
• Context-aware payload placement. SSTI payloads behave differently depending on whether they land inside an HTML attribute, a JSON field, or a URL parameter that’s later rendered server-side; testers adjust encoding and quoting per context rather than reusing one payload everywhere.
• Blind SSTI confirmation. When no output is reflected, testers rely on template functions capable of making an outbound network call or introducing a measurable time delay, confirmed via an out-of-band collaborator domain — mirroring the blind-SSRF and blind-XXE confirmation approach.

SQL Injection

SQL injection tests whether user-controlled input reaches a database query without adequate parameterization. Testers probe every parameter that could plausibly touch a query — not just form fields, but headers like User-Agent and X-Forwarded-For, and cookies — watching for error messages, altered responses, or timing differences that indicate the query structure has been influenced. Once a suspected injection point is found, automated tools can map the extent of the flaw, but manual confirmation always comes first. A frequently overlooked variant is second-order injection, where data stored safely in one request is later used unsafely in a completely different query.

Advanced techniques:

• Boolean-blind and time-blind extraction. When no error or data is reflected, testers use conditional payloads that alter the response only when a guessed condition is true, or that introduce a deliberate database delay (e.g. a conditional sleep) — extracting the database character by character purely from response timing or content differences.
• Out-of-band exfiltration. On databases with network functions available, injected queries can trigger a DNS or HTTP lookup to a tester-controlled domain, encoding extracted data in the subdomain itself — useful when both error-based and blind-boolean channels are unavailable.
• Second-order and stored injection tracing. Because the vulnerable sink is often several requests removed from the injection point, testers keep a map of every field that gets written to storage and re-tested every downstream feature (exports, admin search, reporting) that later reads it back into a query.
• WAF evasion through encoding and comment obfuscation. Inline comments, alternate casing, and whitespace substitution (tabs, newlines) are used to break up signature-based detection while preserving the query’s logical structure.
• NoSQL and GraphQL-adjacent injection. The same logical-flaw mindset extends to NoSQL query operators and GraphQL resolver arguments, where testers substitute structured objects (rather than strings) into parameters to alter query logic in ways a WAF tuned for SQL syntax won’t catch.

IDOR and Broken Access Control

Insecure Direct Object References occur when an application exposes internal identifiers — sequential IDs, GUIDs, or slugs — and fails to verify that the requesting user actually owns the referenced resource. Testing this class requires creating multiple accounts across different roles and tenants, then systematically substituting one user’s identifiers into another user’s authenticated session to see whether access is granted. IDOR severity often depends on discoverability: a GUID-protected resource looks safe until a separate endpoint is found that lists or leaks those GUIDs, at which point the two issues chain into a complete, high-severity exploit.

Advanced techniques:

• Parameter pollution and format-switching. Testers try the same object reference across every API version, content type, and parameter style the application exposes (query string, JSON body, path segment, legacy XML endpoint) since access control is frequently implemented once and forgotten on secondary interfaces.
• HTTP method and verb tampering. An endpoint that correctly checks ownership on GET may skip the check entirely on PUT, PATCH, or a bulk/batch variant of the same action.
• Horizontal-to-vertical escalation chaining. Testers combine an IDOR that leaks another user’s data with a second flaw (a predictable role parameter, a mass-assignment field) to escalate from viewing another user’s record to acting with another user’s privileges.
• Mass assignment auditing. Sending additional, undocumented JSON fields ("role":"admin", "isVerified":true) alongside a legitimate update request tests whether the backend blindly binds every field in the request body to the underlying object rather than an explicit allow-list.
• GraphQL object-level authorization gaps. Because a single GraphQL query can request nested objects across ownership boundaries, testers walk the schema for relationships (e.g., user { organization { invoices } }) that may not carry the same authorization check as the top-level field.

Cross-Site Request Forgery (CSRF)

CSRF testing focuses exclusively on authenticated, state-changing actions — email changes, password updates, financial transactions — rather than login or logout flows. The core checks are straightforward: does the request include an anti-CSRF token, does the server actually validate it, and what does the SameSite cookie attribute allow? CSRF is rarely high-severity in isolation, but it becomes serious quickly when chained — for example, forging an email-change request before triggering a password reset can lead directly to account takeover.

Advanced techniques:

• Token leakage via Referer or logs. Even when a CSRF token is validated correctly, testers check whether the token itself leaks through the Referer header on outbound cross-origin requests, through analytics scripts, or through server logs.
• JSON-based CSRF. Applications that assume CSRF is impossible for JSON endpoints (because forms can’t natively send application/json) are tested with content-type confusion — submitting form-encoded data that the backend still parses as JSON, or exploiting a lenient Content-Type sniffing implementation.
• SameSite bypass via subdomains or sibling sites. If cookies are scoped broadly (SameSite=Lax combined with a vulnerable subdomain, or a shared parent domain with another application), that sibling origin can sometimes be used to stage the forged request as if it were same-site.
• Login CSRF. Rather than targeting an authenticated action, some testing focuses on forcing an unauthenticated victim into the attacker’s own session — useful for tricking a user into unknowingly saving payment details or search history to an attacker-controlled account.

Server-Side Request Forgery (SSRF)

SSRF arises when an application can be coerced into making HTTP requests to attacker-chosen destinations — commonly through features like link previews, webhook configuration, or PDF generation. Testers first confirm the vulnerability blindly, using an out-of-band collaborator service to detect any outbound request, then escalate toward internal network resources and cloud metadata endpoints where credentials are often exposed. SSRF is treated as a serious finding because it frequently provides a foothold into infrastructure that is otherwise unreachable from the public internet.

Advanced techniques:

• Filter-bypass encoding. When an application blocks obvious internal addresses like 127.0.0.1 or 169.254.169.254, testers rotate through alternative representations — decimal or octal IP encoding, IPv6 loopback forms, or DNS names that resolve to an internal address — to slip past naive string-based filters.
• Open redirect chaining. An SSRF filter that only validates the initial URL can sometimes be defeated by pointing it at an attacker-controlled redirect that then 302s to the real internal target, since many HTTP clients follow redirects by default.
• Protocol smuggling. Beyond plain HTTP, testers check whether the vulnerable function will follow alternate URL schemes (file://, gopher://, dict://) that some libraries support by default, each opening different secondary attack surface.
• Cloud metadata targeting. In cloud-hosted environments, confirmed SSRF is escalated toward the instance metadata service to attempt retrieval of temporary credentials, which is frequently the highest-impact outcome of an SSRF finding.
• DNS rebinding. For cases where the target validates a hostname at request time but a separate process performs the actual connection, testers use a DNS record with a very short TTL that resolves to an allowed address on the first lookup and an internal address on the second.

XML External Entity (XXE) Injection

XXE affects any feature that parses XML — including, less obviously, file formats like DOCX, XLSX, and SVG, which are themselves XML-based archives under the hood. A vulnerable parser that resolves external entities can be used to read local files on the server or, in blind scenarios, to trigger out-of-band callbacks. Testers check every XML ingestion point, including document and image upload features that don’t outwardly look XML-related.

Advanced techniques:

• Blind exfiltration via parameter entities. When the parser doesn’t reflect data directly in the response, testers use external parameter entities hosted on a tester-controlled server to chain a local file’s contents into an outbound request, confirmed through the collaborator server’s access log.
• Error-based exfiltration. Deliberately malformed XML can coerce the parser into including the content of a targeted file inside its own error message, giving a one-shot read without needing an out-of-band channel.
• File-format-disguised XXE. Because DOCX, XLSX, PPTX, and SVG are XML under the hood, testers repackage a malicious entity declaration inside an otherwise normal-looking upload of one of these formats to reach parsers that aren’t obviously “XML endpoints.”
• XInclude-based attacks. On parsers where DOCTYPE declarations are stripped or blocked but the XInclude feature is still enabled, testers substitute an XInclude directive to achieve a similar file-read primitive without ever declaring an external entity.

Local and Remote File Inclusion (LFI/RFI)

LFI and RFI target parameters that reference files or paths on the server — file=, page=, template= and similar. Directory traversal sequences test whether the application can be tricked into reading files outside its intended directory, while language-specific wrappers (notably PHP's stream wrappers) can sometimes be abused to read source code or execute attacker-controlled input directly.

Advanced techniques:

• Traversal filter bypasses. When basic ../ sequences are stripped, testers try encoded variants (URL-encoded, double-encoded, or overlong UTF-8 sequences) and non-recursive stripping bypasses (....//), which defeat filters that only remove the pattern once.
• Null-byte and path-truncation tricks. On older or misconfigured stacks, appending a null byte or exceeding a path-length limit can truncate a forcibly appended file extension, allowing a non-matching file to be read.
• Log and session poisoning to RCE. LFI alone only reads files, but if an attacker can influence the content of a file the application later includes — a web server log via a crafted User-Agent, or a PHP session file — LFI can be escalated into full code execution.
• PHP wrapper abuse. Stream wrappers such as php://filter can be used to base64-encode a target file's contents on the fly, letting a tester read source code that isn't returned as valid output otherwise, while php://input or data:// wrappers can sometimes be leveraged for direct code execution when allow_url_include is enabled.
• RFI via attacker-hosted payloads. When remote inclusion is possible, testers host a minimal payload file on infrastructure they control and reference it through the vulnerable parameter to confirm code execution rather than just file disclosure.

File Upload Vulnerabilities

File upload testing examines whether an application properly restricts what can be uploaded and, critically, whether uploaded files can later be executed. Testers check extension filtering, content-type validation, and double-extension tricks, and — separately — whether uploaded SVG or document files can be used to deliver XSS or XXE payloads. The key question after any successful bypass is whether the uploaded file is served from a web-accessible path.

Advanced techniques:

• Extension and MIME confusion. Testers try double extensions (shell.php.jpg), null-byte truncation, case variation (.PhP), and alternate server-recognized extensions (.phtml, .phar) to find gaps between the filter's allow-list and what the web server will actually execute.
• Magic-byte and content-sniffing bypass. When the server validates file signatures rather than extensions, a polyglot file can be constructed that satisfies the expected magic bytes of an allowed format (like a valid GIF header) while still containing executable content later in the file.
• Metadata and filename-based injection. Beyond the file body itself, testers check whether EXIF metadata or the filename field is later rendered unsanitized elsewhere in the application, turning an “upload” feature into a stored XSS or path-traversal vector.
• Archive-based attacks. ZIP or TAR uploads that are automatically extracted server-side are tested for path traversal within the archive’s own file listing (“zip-slip”), which can write files outside the intended extraction directory.
• Race conditions in upload-then-scan flows. When an antivirus or validation scan runs asynchronously after the file is already accessible, a brief race window sometimes allows the file to be accessed or executed before it’s removed.

Command Injection

Command injection targets any parameter that appears to feed into a system-level call — hostnames, IP addresses, filenames. Testers use shell metacharacters to test whether additional commands can be chained onto the intended one, confirming blind cases through timing delays or out-of-band network callbacks rather than relying on visible output.

Advanced techniques:

• Blind confirmation via timing and DNS. In place of visible output, testers append a command that introduces a measurable delay, or one that triggers a DNS lookup to a tester-controlled domain, confirming execution purely through side channels.
• Filter evasion through shell substitution. When specific characters like spaces or slashes are blocked, testers substitute shell-native alternatives (variable expansion, brace expansion, or alternate field separators) to reconstruct the same command without using the filtered characters directly.
• Argument injection versus full command injection. Even when arbitrary command chaining is blocked, some applications concatenate user input as an argument to a fixed command; testers check whether that argument position can still be abused to change the target command’s behavior (e.g., pointing a fixed backup utility at an unintended path).
• Language-specific eval sinks. Beyond OS command injection, testers check for unsafe use of language-level evaluation functions that accept user input, which carry the same impact as shell injection but require different payload syntax entirely.

Open Redirects

Open redirect testing checks whether redirect-related parameters can be pointed at attacker-controlled domains. On their own, these are considered low-severity, but they become meaningfully more serious when chained with other flows — most notably OAuth, where a manipulated redirect can be used to steal authorization codes.

Advanced techniques:

• Allow-list bypass via URL parsing quirks. Backend validation logic that checks for a “trusted” substring or domain suffix can often be defeated with crafted URLs that exploit inconsistencies between how the validator and the browser parse the same string (userinfo tricks, backslash normalization, or unexpected subdomain matches).
• Protocol-relative and malformed-scheme tricks. Testers try protocol-relative URLs and unusual scheme formatting to see whether validation logic anchored to http(s):// can be bypassed entirely.
• OAuth redirect_uri chaining. When an OAuth flow's redirect target isn't strictly validated, a redirect chain is used to route the authorization code or token to an attacker-controlled endpoint, turning a "low severity" open redirect into full account takeover.

Authentication and Session Management

This category covers a wide surface: username enumeration through inconsistent error responses, weaknesses in password-reset token generation and reuse, JWT implementation flaws (including algorithm confusion and weak signing secrets), and session lifecycle issues such as tokens that fail to rotate after login or remain valid after logout or password change. Cookie security flags — HttpOnly, Secure, and SameSite — are checked as a baseline on every session-bearing cookie.

Advanced techniques:

• JWT algorithm confusion. Testers check whether a server that expects an asymmetrically signed token (RS256) can be tricked into verifying a token with the public key used as an HMAC secret (HS256), and separately whether the alg: none header is honored, both of which allow token forgery without knowing any secret.
• Weak-secret brute forcing. For HMAC-signed JWTs, the signing secret itself is tested against common wordlists offline, since a guessable secret allows unlimited token forgery.
• Password-reset token analysis. Reset tokens are examined for predictability (sequential values, timestamp-derived tokens, insufficient entropy) and for whether they properly expire and invalidate after first use.
• Session fixation. Testers check whether a session identifier issued before login remains valid and unchanged after successful authentication, which would let an attacker pre-seed a victim’s session.
• Race conditions in multi-factor and account-recovery flows. Concurrent requests to OTP verification or account-recovery endpoints are tested for logic that doesn’t properly lock state between the check and the action, occasionally allowing an attempt limit or a one-time code to be reused.
• Username enumeration timing analysis. Even when error messages are generic, subtle response-time differences between “valid username, wrong password” and “invalid username” can still allow enumeration through statistical timing analysis.

Business Logic Flaws

Business logic testing is where automated scanners are least useful and manual understanding of the application matters most. Testers look for race conditions in limited-resource operations (coupon redemption, referral bonuses), acceptance of negative values in quantity or transfer fields, the ability to skip required steps in a multi-step workflow, and — a perennial favorite — whether pricing, roles, or permissions are trusted from client-supplied data rather than enforced server-side.

Advanced techniques:

• Race condition exploitation via concurrent requests. Sending a burst of identical requests at the same instant (a coupon redemption, a fund transfer, a limited-inventory purchase) tests whether the backend properly locks the resource between the balance check and the balance update, a class of bug that single-threaded manual testing routinely misses.
• Workflow step-skipping. Testers replay requests out of the expected sequence — jumping straight to a “confirm order” endpoint without a valid “add payment method” step, for instance — to see whether server-side state actually enforces the intended order of operations.
• Price and parameter tampering across currencies/units. Beyond simple negative-number tests, testers check whether switching currency, unit, or bundle-size parameters mid-transaction can be used to apply a discount calculated against one value to a total calculated against another.
• Rate-limit and quota bypass. Testers rotate identifying headers, use alternate API versions, or exploit differences between a rate limiter applied at the load balancer versus the application layer to exceed intended usage limits.
• Trust-boundary abuse between microservices. In service-oriented architectures, a check enforced correctly at the public-facing gateway is sometimes absent on an internal service that assumes all callers are already trusted — reachable if any other flaw (SSRF, IDOR) provides a path to call it directly.

Modern Attack Surface (2026)

As application architectures evolve, so does the testing surface:

• GraphQL endpoints are checked for introspection left enabled in production, missing authorization on mutations, and batching abuse that can bypass rate limiting.
• WebSockets require the same rigor as HTTP endpoints — message tampering, cross-site WebSocket hijacking, and tokens embedded insecurely in message payloads are all in scope.
• OAuth 2.0 / OIDC flows are tested for missing or reused state parameters, weak redirect_uri validation, authorization code reuse, and the absence of PKCE in public clients.
• Exposed secrets in client-side JavaScript — API keys, tokens, and credentials — are surfaced by scanning bundled JS files pulled from historical URL archives.
• Prototype pollution in JavaScript applications is tested by attempting to modify Object.prototype through crafted parameters, then confirming impact in the browser console.
• Cache poisoning is tested through unkeyed headers that influence a cached response without being part of the cache key, potentially poisoning content served to every subsequent visitor.
• Subdomain takeover is identified by finding DNS records pointing to decommissioned third-party services that can be re-claimed by an attacker.

Why This Structure Matters

None of these vulnerability classes exist in isolation during a real assessment. Part of what separates a strong bug bounty submission from a mediocre one is the ability to demonstrate concrete impact — and impact frequently comes from chaining. An open redirect alone is a footnote; an open redirect that leaks an OAuth authorization code is an account takeover. A GUID-based IDOR looks contained until a separate leak reveals those GUIDs at scale. This is why methodical, phase-based testing — recon, manual exploration, deep proxy analysis, then structured vulnerability testing across each of the categories above — consistently outperforms scattershot scanning: it builds the contextual understanding needed to recognize when two “low” findings are actually one “critical” one.

This article summarizes public methodology from the 2026 Practical Bug Bounty Guide by The-XSS-Rat, condensed for a general security audience.