Web Application Pentest & Bug Bounty Checklist

Read the bug bounty program policy or engagement contract in full before touching anything, noting in-scope domains, wildcard rules, explicitly out-of-scope assets, and any prohibited techniques such as automated scanning or denial of service. Keeping a written copy of scope decisions prevents accidental testing of third-party or excluded systems later in the engagement.

Query WHOIS records for the target's root domains to identify the registrant organization, registrar, creation date, and name servers. This can reveal related organizations, acquisition history, or shared infrastructure that expands the effective attack surface.

Look up the autonomous system numbers owned by the target organization and enumerate the associated IP ranges. This helps discover hosts that are not tied to a known hostname but still belong to the organization, such as legacy servers or internal tooling exposed to the internet.

Pull subdomain data from certificate transparency logs, DNS aggregators, and search engine indexes without sending any traffic to the target itself. Passive collection is low-noise and often surfaces forgotten staging or admin subdomains that active brute-forcing would miss.

Actively resolve candidate subdomain names against the target's authoritative name servers using curated wordlists, then confirm each hit resolves to a live IP. Combine multiple wordlist sources and permutation techniques to catch naming patterns unique to the organization.

Take discovered subdomains and generate likely variations by combining environment, region, and versioning keywords such as dev, staging, uat, and api-v2. Resolving these permutations frequently uncovers pre-production hosts that received less security hardening than production.

Search CT log aggregators for every certificate ever issued containing the target's domain, including wildcard and SAN entries. Because certificates are logged publicly and permanently, this technique can reveal hosts that were only briefly live.

Query A, AAAA, MX, TXT, NS, and CNAME records for all known domains and subdomains to map hosting providers, mail infrastructure, and third-party service integrations referenced in TXT records such as SPF or verification tokens. TXT records in particular sometimes leak internal service names or cloud account identifiers.

Test whether the authoritative name servers for the target domain will hand over a full zone transfer (AXFR) to an unauthenticated client. A misconfigured server that allows this discloses the complete internal DNS structure in a single request.

For every CNAME pointing to a third-party service such as a cloud storage bucket, PaaS app, or SaaS platform, verify whether the referenced resource still exists. A dangling record pointing to an unclaimed resource lets an attacker register that resource and serve content under the victim's trusted subdomain.

Search for cloud storage buckets, blob containers, and managed database endpoints named after the target organization or its products, then check their access permissions. Publicly writable or listable buckets are a recurring source of sensitive data exposure in bug bounty programs.

Search public source code repositories, gists, and package registries associated with the organization or its employees for hardcoded API keys, internal hostnames, and configuration files. Developers frequently commit credentials or infrastructure details that remain retrievable through commit history even after later removal.

Use advanced search operators to find indexed pages, exposed directories, error messages, and documents that reveal internal paths, credentials, or configuration data. Search engines cache content long after it is removed from a live site, so dorking can reveal historical exposures too.

Search internet-wide scanning platforms by organization name, SSL certificate hash, or favicon hash to find hosts belonging to the target that are not linked from any known domain. This is especially effective for finding forgotten internal admin panels or IoT-adjacent management interfaces exposed directly on an IP address.

Pull historical URL snapshots from web archiving services to recover old endpoints, parameter names, and files that may still be functional even though they were removed from current navigation. Archived JavaScript files are especially valuable for recovering old API paths.

Identify employee names, roles, and technology mentions from professional networking sites, job postings, and conference talks to understand the tech stack in use and potential social engineering angles. Job listings in particular often disclose specific frameworks, cloud providers, and internal tool names.

Send lightweight HTTP and HTTPS probes to every resolved subdomain to determine which hosts are actually serving content, capturing status codes, titles, and redirect chains. This turns a large raw subdomain list into a prioritized set of reachable web applications to test further.

Capture screenshots of every live host to quickly spot login portals, admin panels, default install pages, and error pages across a large host list. Visual triage is much faster than manually browsing each host and helps prioritize which targets deserve the most testing time.

Compute a hash of each site's favicon and compare it against known hashes for common frameworks, admin panels, and appliances. This can quickly identify the underlying software stack across many hosts without crawling each one individually.

Determine whether traffic is routed through a content delivery network or web application firewall, and if so attempt to identify the real origin IP address behind it. Knowing whether a WAF is present changes both testing pace and payload crafting strategy for later stages.

Scan the complete 65535-port range on each in-scope IP rather than relying on a default top-N port list, since applications are frequently hosted on non-standard ports. Save raw output for later reference and to avoid re-scanning the same host unnecessarily.

Probe UDP ports associated with DNS, SNMP, NTP, and other commonly misconfigured services, since these are often overlooked relative to TCP scanning. Misconfigured SNMP or DNS services can leak configuration data or allow amplification-based abuse.

Grab service banners and version strings for every open port to identify the exact software running, which narrows down the set of known weaknesses and misconfigurations worth investigating. Cross-reference identified versions against vendor advisories and changelogs.

Execute default and vulnerability-category scripts against open services to surface low-hanging issues such as anonymous authentication, default credentials, or known misconfigurations. Treat script output as a lead to manually verify rather than a confirmed finding.

Analyze response headers, cookie names, error pages, and static asset paths to identify the web server, application framework, CMS, and JavaScript libraries in use. Knowing the exact stack lets you pull up framework-specific default paths, known misconfigurations, and version-specific behavior.

Check whether the server discloses detailed version information through headers such as Server or X-Powered-By, and note it for correlation with known issues in that exact version. Overly verbose version banners make targeted exploitation easier for an attacker.

Identify every port serving TLS, including non-standard HTTPS ports and internal service endpoints, so certificate and cipher analysis in the TLS testing stage covers all of them rather than only port 443. Some organizations run separate certificates or weaker configurations on secondary TLS ports.

For sites built on a known content management system, enumerate the CMS version and any installed plugins or themes through their characteristic file paths and readme files. Outdated plugins are one of the most common sources of exploitable vulnerabilities on CMS-driven sites.

Trigger an application error and observe whether a verbose debug page is returned, revealing stack traces, source file paths, environment variables, or the framework's internal configuration. Debug interfaces left active in production frequently allow arbitrary code execution or full configuration disclosure.

Search for common admin panel paths, management consoles, and infrastructure dashboards such as database admin tools or CI/CD interfaces exposed on the same host or port range. These interfaces are high-value targets since they often bypass normal application authentication.

Attempt vendor-documented default usernames and passwords against any management interface, database, or appliance login discovered during scanning. Default credential exposure remains a persistent and easily fixed issue that continues to grant full system access when overlooked.

From a position with access to the host or through an SSRF primitive, determine whether the cloud provider's instance metadata service is reachable and returns credentials or configuration data. Exposed metadata endpoints are a frequent pivot point from a web vulnerability to full cloud account compromise.

Compare response headers, TLS certificates, and timing across repeated requests to determine whether traffic is distributed across multiple backend servers with potentially inconsistent configurations. An inconsistently patched backend behind a load balancer can be reachable only intermittently, which explains flaky findings.

Look for staging, UAT, QA, or beta versions of the application that mirror production functionality but often run with weaker authentication, verbose errors, or outdated patches. These environments are frequently in scope for bug bounty programs and yield disproportionately more findings.

Determine whether requests pass through an API gateway, reverse proxy, or backend-for-frontend layer, since these components often apply their own routing, authentication, and rate-limiting rules that can be tested and bypassed independently of the main application.

Send an OPTIONS request and try alternate verbs such as PUT, DELETE, TRACE, and PATCH against discovered endpoints to see which unexpected methods are accepted. Some frameworks apply authentication or filtering logic only to specific verbs, leaving others unintentionally open.

Identify which cloud provider, data center, or hosting company serves each IP address, which helps anticipate provider-specific misconfiguration patterns such as storage bucket naming conventions or metadata service behavior. This also clarifies which provider-specific disclosure or safe-harbor rules might apply during testing.

Cross-reference every identified software name and version against public vulnerability databases and vendor advisories to build a prioritized hypothesis list before active exploitation testing begins. This step turns raw fingerprint data into an actionable test plan rather than a simple inventory.

Run a wordlist-based content discovery scan against each host to reveal directories, backup files, and endpoints that are not linked from the visible site navigation. Vary wordlists and file extensions based on the fingerprinted technology stack to improve hit rate.

Download and statically analyze every JavaScript bundle served to the client, extracting API paths, hidden parameters, and hardcoded keys or tokens. Modern single-page applications often expose their entire backend API surface inside client-side bundles that are never manually reviewed by developers.

Look for .map files alongside minified JavaScript bundles, since a source map reconstructs original, human-readable source code including comments and internal variable names. Exposed source maps can reveal internal logic, hidden endpoints, and sometimes secrets that were never meant to reach the client.

Fetch robots.txt and any sitemap files to find paths that the site owner intentionally tried to keep out of search engine indexes, which are often the same paths an attacker finds interesting, such as admin sections or internal tools. Treat every disallowed path as a lead to investigate directly rather than to avoid.

Probe for common backup extensions, editor swap files, and exposed .git or .svn directories at the site root, since these can allow full source code reconstruction. Recovering an exposed .git directory in particular can hand over entire application source, commit history, and embedded secrets.

Search for OpenAPI/Swagger definitions, GraphQL introspection endpoints, or Postman collections published alongside the application, since these documents describe every endpoint, parameter, and expected data type in detail. Treat any discovered schema as a direct map for building a complete test plan against the API.

Send requests with large sets of candidate parameter names to each endpoint and observe response differences to detect parameters the application silently accepts but does not document. Hidden parameters frequently enable debug behavior, alternate output formats, or bypass logic not exposed through the normal UI.

Run an authenticated crawl through every reachable link, form, and script-triggered navigation path to build a comprehensive map of the application's functionality before targeted testing. A thorough crawl catches multi-step workflows that simple directory brute-forcing will never discover.

Once a base filename is found, try alternate extensions such as .bak, .old, .json, .xml, and language-specific source extensions to reveal a raw or backup version of the same resource. A compiled or rendered endpoint sometimes has an unprotected raw source file sitting alongside it.

Send requests with varying Host headers against a discovered IP to reveal virtual hosts that are not resolvable through public DNS but are still served by the same web server. Internal or staging applications are sometimes reachable this way even though no public subdomain points to them.

Aggregate query string parameters seen in archived crawls of the domain to assemble a target-specific parameter wordlist for fuzzing. Parameters that existed in a past version of the application sometimes still function against current backend code even if the frontend no longer sends them.

Send malformed input designed to trigger server errors and inspect responses for file system paths, internal hostnames, or stack traces that reveal application structure. Even a generic error page sometimes leaks a full server-side file path in an HTML comment or header.

Check Cache-Control and related headers on sensitive or personalized pages to confirm they are not being cached by shared proxies or CDNs in a way that could leak one user's response to another. This overlaps with later cache-poisoning testing but starts with a simple inventory of what gets cached at all.

Probe common GraphQL paths and attempt an introspection query to retrieve the full schema, including types, fields, and mutations that may not be used by the current frontend. A schema left introspectable in production discloses the entire data model and often reveals administrative operations never intended for public use.

Decompile the organization's mobile applications to recover hardcoded API base URLs, endpoint paths, and embedded keys that may target the same backend as the web application. Mobile clients often call broader or less-restricted API surfaces than the public web frontend.

Manually review page source for HTML comments, inline scripts, and metadata containing developer notes, TODOs, or references to unlinked functionality. Developers occasionally leave commented-out login bypasses or references to internal-only pages directly in shipped markup.

Once parameters are enumerated, fuzz their values with boundary, type-confusion, and special-character payloads to observe distinct application behavior that hints at underlying logic, such as debug flags, feature toggles, or role indicators. Recording response length and status code differences during this pass helps target later vulnerability-specific testing.

Catalog every third-party JavaScript, widget, and analytics integration loaded by the application, since a compromised or overly permissive third-party script executes with the same trust as first-party code. This inventory also feeds into later Subresource Integrity and CSP header review.

Compare error messages, response timing, and status codes returned for valid versus invalid usernames on the login form to see if the application distinguishes them. An attacker can use a confirmed enumeration channel to build a target list of valid accounts before running credential attacks.

Attempt to register with an email address that already has an account and observe whether the response differs from a fresh registration. Registration flows are a common place where enumeration is accidentally reintroduced even when the login form itself is hardened.

Submit repeated incorrect login attempts to determine whether the application implements rate limiting, progressive delays, CAPTCHA, or account lockout, and whether any of these controls can be bypassed via alternate headers or endpoints. Missing or bypassable lockout controls make credential stuffing and password guessing practical at scale.

If a lockout mechanism keys off client IP address, test whether spoofing headers such as X-Forwarded-For, X-Real-IP, or True-Client-IP resets the attempt counter. Applications that trust client-supplied IP headers for rate-limiting decisions can be trivially bypassed by rotating a header value on every request.

Simulate low-and-slow login attempts using distributed source patterns and previously breached credential pairs (with authorization and using non-real accounts) to evaluate whether anomaly detection catches distributed attack patterns rather than only per-IP thresholds. This clarifies whether the login endpoint's defenses generalize beyond simple rate limiting.

Attempt to set weak, common, or previously breached passwords during registration and password change to confirm the application enforces meaningful complexity and checks against known-compromised password lists. Weak policy enforcement compounds the impact of any credential-guessing weaknesses found elsewhere.

Collect multiple password reset tokens and examine whether they are cryptographically random, sufficiently long, and free of predictable patterns tied to time or user ID. A predictable reset token lets an attacker forge a valid reset link for any account without ever receiving the actual email.

Manipulate the Host header or a similar origin-controlling header on a password reset request to see whether the generated reset link embeds an attacker-controlled domain. If the victim clicks the resulting link, their valid reset token is sent to a server the attacker controls.

Check whether a reset token remains valid after the password has already been changed, after a long time period has elapsed, or after being used once successfully. Tokens that survive reuse or never expire extend the window during which an intercepted or leaked link remains exploitable.

After submitting an incorrect MFA code, inspect and tamper with the application's response body or status code to see whether client-side or predictable server-side logic can be coerced into treating the attempt as successful. Some implementations perform the actual authorization decision based on a value that the client can influence.

Determine the length and character space of one-time codes used for MFA or step-up verification, then test whether the endpoint enforces attempt limits or lockout after repeated incorrect submissions. A short numeric code without rate limiting can realistically be brute-forced within its validity window.

Review whether MFA can be disabled, re-enrolled, or bypassed through a recovery code flow without adequately re-verifying the user's identity first. Recovery paths are often built later than the primary MFA flow and receive comparatively less security scrutiny.

Examine the OAuth or SAML single sign-on flow for improperly validated redirect_uri values, missing or predictable state parameters, and token leakage through referrer headers or browser history. Delegated authentication flows introduce their own class of implementation bugs distinct from traditional password login.

Decode any token issued immediately after successful login to check its structure, signing algorithm, and claims for issues that could allow forgery or privilege manipulation, feeding into the deeper JWT analysis performed in the session management stage. Catching an obviously weak token at this stage saves time before broader session testing.

Examine how a persistent login token is generated, stored, and validated across browser sessions, checking whether it is a long-lived bearer credential with no rotation or binding to device fingerprint. A poorly designed persistent token can outlive a password change and grant indefinite access if ever stolen.

Check whether sensitive operations such as changing an email address, disabling MFA, or viewing payment details require re-authentication even within an already active session. Treating every action within a session as equally trusted ignores the risk of a hijacked or shared session being used for high-impact changes.

Test whether a CAPTCHA challenge can be omitted by directly calling the underlying API endpoint, reusing a previously solved token, or exploiting a client-side-only validation check. A CAPTCHA that is not enforced server-side provides no real protection against automation.

Look for cases where the server returns an authentication result as a simple boolean or status flag that client-side JavaScript then uses to decide whether to grant access, without the server itself gating the protected resource. Intercepting and altering such a response can grant access without ever supplying valid credentials.

Register or log in using different casing or Unicode look-alike characters in the username or email field to check for inconsistent normalization between registration, login, and password reset logic. Inconsistent handling can allow account confusion, duplicate account creation, or reset-flow targeting of the wrong stored record.

Check whether logging in with a third-party identity provider automatically links to an existing local account based solely on an unverified email claim. If the identity provider does not itself verify email ownership, an attacker can claim an arbitrary email address and take over the matching local account through the link flow.

Attempt to change the account password from within an authenticated session without supplying the existing password, which would let a session hijacked through another vector (such as XSS or a stolen token) be converted into full, persistent account takeover. Requiring the current password limits the blast radius of a temporarily hijacked session.

Review any security question or knowledge-based recovery mechanism for reliance on publicly discoverable information and for the absence of rate limiting on guesses. Knowledge-based authentication is inherently weak since answers are often guessable or discoverable through OSINT.

Inspect every session cookie for the Secure, HttpOnly, and SameSite attributes, confirming they are set appropriately for the sensitivity of the session they protect. Missing attributes individually seem minor but combine to make cookie theft via network interception or script injection far easier.

Capture a session identifier before authentication, then log in using that same identifier and check whether the server issues a fresh session token afterward. If the pre-authentication session ID remains valid post-login, an attacker who plants a known session ID on a victim can hijack their authenticated session once they log in.

Collect a large sample of session tokens and statistically test them for sufficient entropy and the absence of sequential or time-derived patterns. A session token generated with insufficient randomness can be predicted or brute-forced, allowing an attacker to guess a valid active session belonging to another user.

Log out of the application and then replay the previously captured session token or cookie to confirm the server rejects it rather than only clearing client-side storage. A logout that only deletes the client cookie without invalidating server-side state leaves the session usable by anyone who captured it beforehand.

Leave a session inactive past the documented timeout window and separately test whether a session eventually expires regardless of activity, then confirm the server actually rejects the stale token rather than just hiding UI elements. Sessions that never truly expire increase the value of any token an attacker manages to capture.

Check whether logging in from a second device invalidates the first session, and whether the application provides users visibility into and control over active sessions across devices. Sessions that silently persist without user awareness make it harder for a victim to notice and respond to unauthorized access.

Modify a captured JSON Web Token's header to declare the none algorithm or to switch from an asymmetric to a symmetric algorithm, then check whether the server still accepts the token as validly signed. Both variants exploit implementations that trust the algorithm field from the token itself rather than enforcing a fixed expected algorithm.

Strip, truncate, or replace the signature segment of a JWT entirely and resubmit it to see whether the server still processes the token's claims. A server that fails to reject a token with an invalid or missing signature effectively treats every claim inside the token as attacker-controlled input.

For tokens signed with a symmetric algorithm, run an offline dictionary or brute-force attack against the signing secret using common and leaked wordlists. A weak or default secret lets an attacker forge tokens with arbitrary claims once recovered, since they can then sign new tokens exactly as the server would.

Modify claims such as role, user ID, or scope inside a validly signed token's payload (where a flaw in re-signing or key confusion allows it) or check whether the server ever re-validates claims against a server-side source of truth rather than trusting the token blindly. Even with a valid signature, an application that never cross-checks sensitive claims against its own database is vulnerable to any upstream token manipulation.

Confirm the server actually rejects an expired token rather than only checking expiry client-side, and separately test whether a token issued before logout or password change remains usable afterward. Stateless tokens are hard to revoke by design, so applications need an explicit mechanism such as a blocklist or short expiry paired with refresh tokens.

If the token header includes a key identifier field used to locate the verification key, test whether it can be manipulated to point to an attacker-influenced file, a SQL injection payload, or a path traversal sequence that resolves to a predictable file on disk. A manipulable key lookup lets an attacker control the value used to verify their own forged token.

Check whether a session token can be replayed from a different IP address, user agent, or device without additional verification, which would indicate the server is not binding the token to any contextual signal. While not a substitute for strong tokens, contextual binding adds meaningful friction against straightforward token theft and replay.

Check whether session cookies are scoped more broadly than necessary, such as being set for a parent domain that includes unrelated subdomains, which would expose the cookie to any application hosted on those subdomains. Overly broad cookie scope expands the blast radius of any vulnerability found on an unrelated subdomain.

Determine whether tokens are stored in an HttpOnly cookie, localStorage, or sessionStorage, since storage location directly determines exposure to script-based theft through cross-site scripting. Tokens placed in localStorage are readable by any JavaScript running on the page, removing a layer of protection that HttpOnly cookies provide.

Use a refresh token to obtain a new access token, then attempt to reuse the same refresh token a second time to see whether the server detects the reuse and revokes the entire token family. Proper rotation with reuse detection limits the damage from a refresh token that gets exfiltrated without immediate detection.

Check whether a session token set on the main application is also sent to less-trusted subdomains, third-party integrations, or is embedded in outbound links, referrer headers, or analytics beacons. Even a single overlooked outbound request carrying a session token in a header or URL can hand it to a third party or an attacker-controlled endpoint.

Capture a valid session, then change the account password from a different session and confirm the original session is immediately terminated. If a password change does not invalidate existing sessions, an attacker who already has a hijacked session retains access even after the legitimate user attempts to lock them out.

Systematically substitute IDs, filenames, or reference values in requests with those belonging to other users or objects while authenticated as a low-privileged account, checking whether the server returns data it should have restricted. This is one of the highest-yield tests in any engagement since it is simple to perform and frequently overlooked by developers who assume users will not tamper with visible identifiers.

Using two accounts at the same privilege level, attempt to view or modify each other's data, orders, messages, or settings by swapping session tokens or object identifiers between requests. Horizontal escalation is often missed by testers who only think in terms of privilege tiers rather than peer-to-peer data isolation.

As a low-privileged user, attempt to access administrative endpoints, functions, and UI elements that should be restricted to higher roles, both by guessing hidden URLs and by replaying requests captured from an admin session with the low-privileged token substituted in. Vertical escalation findings are typically rated more severely since they grant capabilities the attacker's own account was never entitled to.

Directly request pages and endpoints that are not linked from the current user's navigation but are known to exist from crawling a higher-privileged role or from client-side JavaScript references. Access control that relies purely on hiding links from the UI rather than enforcing checks server-side offers no real protection against a direct request.

For an endpoint that correctly blocks unauthorized access via GET, retry the same request using POST, PUT, DELETE, or with method override headers such as X-HTTP-Method-Override to see if the authorization check is inconsistently applied per verb. Some frameworks apply access control middleware selectively based on route and method combination, leaving gaps for less common verbs.

Append trailing slashes, encoded characters, case variations, or extra path segments to a restricted URL to see whether the access control layer and the routing layer parse the path differently, allowing the request to reach the protected handler while evading the check. This class of bypass exploits a mismatch between the component enforcing authorization and the component ultimately serving the resource.

Inspect requests during registration, profile updates, and API calls for parameters like role, isAdmin, or accountType that the client can set directly, then attempt to inject an elevated value even though the UI never exposes that option. Trusting a client-supplied privilege field is functionally equivalent to letting users grant themselves admin rights.

In a multi-tenant SaaS application, verify that switching a tenant identifier in a request cannot expose data or functionality belonging to a different customer organization. A tenant isolation failure is especially severe since a single bug can expose every customer's data rather than one individual user's data.

Query individual fields and mutations directly rather than relying on the bundled queries the frontend sends, since GraphQL resolvers sometimes enforce authorization at the query level but miss individual nested fields or mutations that expose the same underlying data. A single unauthorized field buried deep in a nested query can leak data that the top-level query correctly protects.

Compare access control enforcement between single-object endpoints and their batch or bulk equivalents, since bulk operations are sometimes implemented later and separately, missing the per-object authorization check applied by the singular endpoint. A bulk export or bulk update endpoint that skips per-item checks can leak or modify far more data in one request than the equivalent single-item flaw.

Confirm that scopes or permission claims embedded in an access token are actually checked against the specific action being performed, rather than only used to decide whether a request is authenticated at all. Treating any valid token as fully authorized regardless of its declared scope defeats the purpose of fine-grained scoping.

Disable or delete a test account and then attempt to use its previously issued session token or API key to access the application. Access control logic that checks account status only at login time rather than on every request leaves a window where a banned or removed user's existing session keeps working.

Add extra fields to a JSON request body, such as isAdmin or accountBalance, that are not part of the documented request schema but might map directly to internal object properties, and observe whether the server silently accepts and applies them. Frameworks that automatically bind request bodies to internal data models are especially prone to this if they do not explicitly allowlist bindable fields.

Issue an API key scoped to a limited resource or read-only permission and attempt to use it against unrelated resources or write operations to confirm the server enforces the declared scope rather than treating any valid key as fully privileged. Overly permissive key enforcement undermines the entire purpose of offering scoped credentials to integrators.

Compare the exact error returned for a nonexistent object versus one that exists but belongs to another user, since a distinguishable difference reveals the existence and sometimes partial details of data the requester should not be able to confirm at all. Consistent, generic error handling prevents this indirect information leak even when direct access is properly blocked.

In a multi-step process such as checkout, onboarding, or approval workflows, attempt to call a later-stage endpoint directly without completing or having permission for the earlier required stages. Workflow logic that assumes requests will always arrive in the expected sequence can be manipulated by simply calling the final endpoint out of order.

Where an admin panel supports multiple sub-roles such as support staff versus full administrators, verify that each sub-role cannot escalate to actions reserved for a higher administrative tier within the same panel. Multi-tier admin systems often only clearly separate normal users from admins while treating internal admin sub-roles as equally trusted.

Verify whether endpoints that return sensitive, session-bound data also carry an overly permissive Access-Control-Allow-Origin configuration, since the combination allows a malicious website to read authenticated data on the victim's behalf. This item specifically links access control review with the CORS misconfiguration testing performed later in the engagement.

Inject characters such as a single quote into every parameter and observe whether the application returns a database error message that reveals query structure or confirms the injection point. Verbose database errors returned to the client turn a simple syntax probe into a reliable detection technique and often a data extraction channel.

Determine the number of columns returned by the original query and craft a UNION SELECT statement that appends attacker-chosen data into the application's normal output, letting arbitrary table contents be read directly from the page. Union-based extraction is typically the fastest method once a UNION injection point is confirmed exploitable.

Submit paired true and false conditional payloads and compare the resulting page content, length, or behavior to infer database values one bit or character at a time without any direct error or data output. This technique is slower than union-based extraction but works even when the application gives no visible indication that the query succeeded or failed.

Inject a conditional payload that triggers a database sleep or delay function only when a specified condition holds true, then measure response time to infer the condition's result. This method is the fallback of last resort when neither error messages nor visible content differences exist for the injection point.

Where in-band and blind techniques are impractical due to network filtering or extremely long response times, inject a payload that causes the database to make an outbound DNS or HTTP request to an attacker-controlled listener, exfiltrating data through the request itself. This technique can succeed even when the application's own response channel gives absolutely no feedback.

Store a payload through one input that appears safe at the point of entry, then trigger a separate application function later that reads the stored value and uses it unsafely in a query, revealing an injection that only manifests downstream. Second-order injection is easy to miss because the vulnerable sink is disconnected in time and location from the original input point.

Identify any code path where an object-relational mapping layer falls back to raw or dynamically built SQL, such as custom filter strings or raw query helper methods, and test those specifically since ORMs generally protect parameterized queries but not manually constructed ones. Developers sometimes assume an ORM makes an application immune to injection everywhere, which is only true for the parts of the code that stick to the ORM's safe query builder methods.

Replace expected scalar values with NoSQL query operators, such as substituting a password field's string value with a comparison or existence operator object, to see whether the backend blindly passes user-supplied structures into its query without type validation. Because these payloads look like normal JSON rather than escape sequences, they slip past filters designed to catch traditional SQL injection syntax.

On applications backed by a document database, attempt to authenticate by submitting operator-based payloads in the username and password fields instead of literal strings, aiming to make the query match every document rather than a single specific user. This is one of the most immediately impactful outcomes of NoSQL injection since it can grant unauthenticated login as an arbitrary or even the first account in the collection.

Identify parameters that are passed to a server-side shell command or system call, and inject shell metacharacters combined with a benign command such as a delay or DNS callback to confirm code execution at the operating system level. Successful command injection typically leads directly to full server compromise rather than remaining confined to the application layer.

Where command output is not reflected in the response, inject a payload that triggers a DNS lookup or outbound HTTP request to an attacker-controlled listener to confirm execution occurred without needing to see any direct output. Blind detection is essential because many vulnerable code paths execute a command purely for its side effect and never return its output to the user.

Where user input is passed as an argument to a command-line utility rather than concatenated into a shell string, test whether injecting additional flags or argument separators changes the invoked tool's behavior in unintended ways, such as pointing it at a different file or enabling a dangerous option. Argument injection can succeed even when classic shell metacharacter filtering is correctly applied, since it abuses the target program's own argument parsing rather than the shell.

Inject LDAP filter metacharacters into fields that are used to query a directory service, such as login or user search forms, to see whether the filter's logical structure can be altered to return unintended entries or bypass an authentication check. LDAP injection follows the same underlying principle as SQL injection but targets directory query syntax instead of relational query syntax.

When LDAP search results are not directly displayed, use conditional filter payloads and observe subtle differences in application behavior, such as differing response content for a matching versus non-matching condition, to blindly enumerate directory attributes. This mirrors blind SQL injection technique but requires understanding the specific directory schema in use.

Submit a small set of template-syntax polyglot payloads into every input reflected into a rendered page and look for arithmetic evaluation or template-engine-specific error output, which confirms that user input is being parsed as template code rather than treated as inert text. Detecting the specific template engine in use from the response is the critical first step before crafting an engine-specific exploitation chain.

Once a specific template engine is identified, use engine-specific object traversal or built-in function access to reach a code execution primitive, such as invoking the underlying language's process execution function from within the template context. Documenting the full working exploit chain is important for accurately conveying the true severity of the finding rather than reporting only the initial detection payload.

For frameworks that support an expression language for dynamic value resolution, inject expression syntax into fields known to be evaluated server-side and check whether arbitrary expression evaluation or object method invocation is possible. Expression language injection follows the same conceptual pattern as template injection but is specific to frameworks offering this evaluation mechanism outside of a traditional templating context.

Submit an XML document defining an external entity that references a local file path, then check whether the parsed response includes the file's contents, confirming the parser resolves external entities without restriction. This is the most direct XXE variant and typically yields immediate local file disclosure once confirmed.

When entity results are not reflected in the response, host an external DTD on an attacker-controlled server and reference it from the injected XML to exfiltrate file contents through an outbound HTTP or DNS request. This technique is necessary whenever the application processes the XML but never displays the parsed output back to the requester.

Check file formats that are XML under the hood, such as SVG, DOCX, XLSX, and PDF-adjacent formats, when uploaded as profile pictures or documents, since their internal XML structure can carry the same external entity payloads as a direct API request. Developers who sanitize obvious API-level XML input often forget that file upload features parse XML-based file formats through the exact same vulnerable parser.

Submit an XML document defining nested entities that each reference multiple copies of the previous entity, causing exponential expansion in memory when parsed, and monitor whether the server becomes unresponsive or crashes. Unlike classic XXE this variant targets availability rather than confidentiality, exhausting server memory or CPU purely through the parser's entity expansion behavior.

Inject XPath metacharacters and boolean logic into inputs used to query an XML data store to determine whether the query structure can be manipulated similarly to SQL injection, potentially bypassing authentication checks or extracting arbitrary XML node data. Applications that store data in XML rather than a relational database can be just as vulnerable to structural query manipulation as SQL-backed applications.

Identify functionality that evaluates user-supplied strings as executable code, such as a dynamic formula engine or a debug eval endpoint, or that deserializes untrusted data into live objects, and craft payloads targeting the specific language runtime in use. Any confirmed code injection should be treated as immediately critical since it typically grants execution equivalent to full application-level compromise.

Inject carriage return and line feed sequences into input reflected in response headers, such as a redirect target or cookie value, to check whether an attacker can inject arbitrary additional headers or split the response into two separate HTTP messages. Successful response splitting can enable cache poisoning, session fixation, or reflected content injection depending on what the split response is used for downstream.

Supply an arbitrary or attacker-controlled value in the Host header and observe whether the application uses it to construct links, cache keys, or internal routing decisions without validation against an expected allowlist. Host header trust issues underpin several other findings across the checklist, including password reset poisoning and web cache poisoning.

Submit newline and formatting-control characters as part of standard input fields such as usernames or search terms, then review whether these values are written into application logs verbatim in a way that could forge fake log entries or break structured log parsing. Falsified log entries can mislead incident response and cover an attacker's actual activity trail.

Trace how GraphQL argument values flow into backend database or shell calls within resolver implementations, since a GraphQL layer does not inherently sanitize the arguments it passes further into the system. A resolver that builds a raw SQL string or shell command from a GraphQL argument carries exactly the same injection risk as a traditional REST parameter.

Manipulate any parameter that references a filename or path with sequences such as encoded parent-directory traversal to determine whether the application can be coerced into reading, writing, or including a file outside its intended directory. Path traversal frequently leads directly to source code disclosure, configuration file exposure, or local file inclusion depending on how the retrieved file is subsequently processed.

Where an application dynamically includes a file based on user input, attempt to include a local file outside the intended directory and separately test whether a remote URL can be supplied to fetch and execute attacker-hosted code. Remote file inclusion is especially severe since it can grant direct code execution by pulling malicious script content from a server the attacker controls.

For applications with native code components or logging functions that accept a user-controlled format string argument, test whether format specifiers can be injected to read from or write to process memory. This is a lower-frequency finding in modern web stacks but remains relevant for applications built on native language extensions or legacy CGI components.

Inject script-triggering payloads into URL parameters, form fields, and headers that are echoed back in the immediate response, and confirm actual script execution in a real browser context rather than just observing the payload reflected in the raw HTML. Reflected XSS requires a victim to click a crafted link, so document a working proof-of-concept link as part of the finding.

Submit script-triggering payloads through any input that gets persisted and later rendered to other users, such as comments, profile fields, or support tickets, then verify execution occurs when a different session views the affected page. Stored XSS is generally rated more severely than reflected XSS since it can silently affect every user who views the poisoned content without needing to click anything.

Trace client-side JavaScript for cases where data from a source such as the URL fragment, document.location, or postMessage flows into a dangerous sink like innerHTML or eval without sanitization, and confirm exploitability by crafting a URL or interaction that triggers execution entirely within the browser. DOM XSS often evades server-side input filtering entirely since the vulnerable data flow never touches the server at all.

Adjust payload syntax to match the exact HTML, attribute, JavaScript, or CSS context the input lands in, since a payload that works in one context is frequently neutralized by encoding rules specific to another. Understanding output context is essential for confirming a true negative rather than simply giving up after one generic payload fails.

When a straightforward payload is blocked, try alternate encodings, case variation, unusual tag or event handler combinations, and mutation-based payloads that exploit browser HTML parsing quirks to slip past the filter or WAF rule. A blocked initial payload is not proof the input is safe, since filters frequently cover only well-known payload patterns.

Upload files such as SVG images or HTML documents that can embed active script content, then check whether the application serves them with a content type that lets the browser execute the embedded script rather than render them purely as static images. File upload functionality is a commonly overlooked XSS vector since testers often focus only on text input fields.

Submit crafted markdown or rich text input designed to be converted into raw HTML by a rendering library, checking whether the conversion step or a subsequent sanitization pass fails to strip dangerous tags and attributes. Rich text editors are a frequent source of stored XSS since the conversion pipeline from markup to HTML introduces an additional place where filtering can be incomplete.

Review client-side postMessage event listeners to check whether they validate the origin of incoming messages before acting on their content, since a missing or overly permissive origin check lets any embedding page send arbitrary messages that the listener treats as trusted. This is a common DOM XSS and logic-bypass vector in applications embedded within iframes or communicating across windows.

Where a Content-Security-Policy header is present, determine whether it actually blocks execution of a confirmed XSS payload or contains gaps such as unsafe-inline, wildcard sources, or an allowlisted domain that also hosts attacker-uploadable content. A CSP with meaningful gaps provides a false sense of security while still leaving the underlying XSS fully exploitable.

Submit payloads that appear inert as written but get rewritten into an executable form once the browser's HTML parser normalizes malformed markup, exploiting the gap between how a sanitizer parses input and how the browser ultimately renders it. Mutation XSS is particularly dangerous against sanitization libraries that parse and serialize HTML differently than the target browser does.

Determine whether the application exposes any legitimate functionality that could be paired with social engineering to get victims to paste attacker-supplied script into their own browser console, and confirm whether appropriate console warnings are shown to end users. While the security impact of self-XSS is limited compared to other variants, applications handling sensitive data still benefit from mitigating warnings.

Identify requests that change account state, such as updating an email address or transferring funds, and attempt to replay them from a separate origin without any anti-CSRF token to confirm whether the server actually validates request origin before acting. Any state-changing action reachable purely through a predictable request structure is a candidate for cross-site request forgery.

Check whether the anti-CSRF token is actually tied to the user's session and properly invalidated after use where expected, or whether it can be omitted entirely, reused from a different session, or replaced with an empty value without the request being rejected. A CSRF token that exists but is not correctly validated server-side provides no real protection despite appearing present in the request.

Where the application relies solely on the SameSite cookie attribute rather than an explicit token, test cross-site request scenarios that can still succeed despite SameSite restrictions, such as top-level navigation-triggered requests or subdomain-originated requests when the attribute is set to a lenient value. SameSite provides meaningful defense-in-depth but has known edge cases that make it an incomplete substitute for a dedicated CSRF token on highly sensitive actions.

If an endpoint is protected mainly by requiring a JSON content type, which ordinary HTML forms cannot set without triggering a CORS preflight, test whether the check can be bypassed using a content type that browsers still allow simple cross-origin form submission with, such as text/plain carrying a JSON-like body the server still parses. Relying on content-type restrictions as an implicit CSRF defense is fragile if the server-side parser is lenient about the declared type.

Look for state-changing functionality that can be triggered by a simple GET request, since a GET request requires no special cross-origin handling at all and can be forged with nothing more than an image tag or a link. GET requests are meant to be safe and idempotent, so any state change reachable this way is a serious deviation from expected web application design.

Attempt to forge a cross-site login request that logs the victim's browser into an account the attacker controls, which can later be used to capture subsequently entered data such as payment details the victim assumes are associated with their own account. Login CSRF is often overlooked since testers focus on protecting authenticated actions and forget the login endpoint itself can be a CSRF target.

Check whether attacker-controlled HTML elements with specific id or name attributes can override expected global JavaScript variables or DOM references that application code relies on, a technique known as DOM clobbering that can achieve script execution or logic bypass without a traditional script tag. This is a subtler variant worth testing on applications with heavily sanitized but not fully locked-down HTML input.

Submit HTML and script-like payloads into fields that populate transactional emails, such as a display name or order note, and review the rendered email in common mail clients for injection effects ranging from layout manipulation to script execution in webmail clients that render embedded scripts. Email rendering engines vary widely in how much markup they honor, making this an inconsistent but occasionally high-impact vector.

Verify that every step of a multi-step form or wizard enforces its own token validation rather than only the final submission step, since an intermediate step that skips validation can sometimes be chained into forging the overall multi-step action. Developers occasionally focus CSRF protection only on the final confirmation request and overlook intermediate steps that still perform meaningful state changes.

Submit payloads that call back to an external listener into fields that are typically only viewed by internal staff, such as support tickets, contact forms, or user agent strings, since the payload's execution context (an internal admin dashboard) is invisible to the tester's own browser session. Blind XSS findings often carry outsized impact since they execute in the browser of an internal, frequently higher-privileged user.

Where a specific client-side or server-side HTML sanitization library is identified, test payload patterns known to exploit parsing inconsistencies specific to that library rather than only generic XSS payloads. Different sanitizer implementations have historically differed in how they handle malformed or unusual markup, and understanding the specific library in use focuses testing effort effectively.

Identify any parameter that causes the server to fetch a URL, such as a webhook target, avatar-from-URL feature, or PDF-generation input, and supply an attacker-controlled listener address to confirm whether the server issues an outbound request. Confirming basic out-of-band interaction is the first step before probing for access to internal-only resources.

Once basic SSRF is confirmed, target internal IP ranges and common internal service ports to map reachable internal infrastructure and retrieve responses from services never intended to be internet-facing. This escalates a simple outbound-request confirmation into a genuine internal network reconnaissance and access capability.

Direct a confirmed SSRF primitive at the cloud provider's well-known metadata service address to attempt retrieval of temporary credentials, instance identity documents, or configuration data assigned to the server's compute instance. This is consistently one of the highest-impact outcomes of SSRF since recovered credentials often grant broad access to the surrounding cloud environment well beyond the vulnerable application itself.

Where the application does not return any fetched content in its response, rely purely on DNS or HTTP callback confirmation from an external listener to prove the request occurred, then reason about likely internal impact even without direct response visibility. Blind SSRF still carries serious risk since it can be chained with internal service side effects even when the tester cannot read the response directly.

Where the vulnerable fetch supports arbitrary schemes, test whether protocols beyond HTTP, such as file, gopher, or dict, can be used to read local files or craft raw requests to non-HTTP internal services. Supporting unnecessary protocol handlers significantly widens what an SSRF primitive can be used to reach and abuse.

Where the application attempts to restrict outbound destinations with an allowlist or blocklist, test bypass techniques such as alternate IP encodings, DNS rebinding, redirect chains, and unusual hostname formats that resolve to a restricted address after the filter's initial check has already passed. Filters implemented as a single string check at request time are especially prone to time-of-check-to-time-of-use bypass through DNS behavior.

Configure a domain with a very short TTL that first resolves to a permitted external address for validation and then rebinds to an internal address by the time the actual fetch occurs, exploiting the gap between validation and use. This technique specifically targets applications that validate a URL's resolved IP once and then trust it for the remainder of the request lifecycle.

Review any user-configurable webhook, callback URL, or third-party integration feature specifically for SSRF, since these features are explicitly designed to have the server make outbound requests to a user-supplied destination, making them a naturally high-risk area deserving dedicated attention. The intended functionality itself often blurs the line between legitimate use and exploitation, so restriction to genuinely external, non-internal targets needs explicit verification.

Identify parameters controlling post-action redirect destinations, such as after login or logout, and supply a fully attacker-controlled external URL to confirm whether the application redirects there without validating that the destination stays within the trusted domain. Open redirects are commonly underrated but are frequently chained into phishing and OAuth token theft attacks.

Where a basic allowlist or same-domain check is applied to the redirect target, test bypass patterns such as protocol-relative URLs, backslash substitution for forward slashes, embedded credentials before an @ symbol, or double-encoding to slip past naive string matching. Redirect validation implemented with simple prefix or substring checks is particularly susceptible to these bypass patterns.

Where an open redirect exists on a domain that is also a registered OAuth redirect URI or an allowed subpath under one, test whether it can be used to redirect an authorization code or access token to an attacker-controlled endpoint after a victim completes an OAuth flow. This chain converts a moderate-severity redirect issue into a full account takeover primitive.

Where the application converts user-supplied or user-influenced HTML into a PDF or image server-side, test whether embedded remote resources or local file references are fetched by the underlying rendering engine, which often runs with more capability than a typical browser sandbox. Headless rendering engines used for document generation are a frequently overlooked SSRF and local file disclosure vector.

Review functionality that imports data by fetching a user-supplied URL, such as importing a profile picture, RSS feed, or CSV file from a remote link, since these convenience features are essentially purpose-built SSRF vectors if the fetch is not restricted to safe external destinations. Confirm both content leakage and internal network reachability through this specific feature category.

Trace every return URL, callback URL, or continue parameter used across login, logout, and third-party payment redirect flows specifically, since these carry a higher trust expectation from users and are prime targets for redirect-based phishing chains. A single overlooked return parameter in a checkout flow can be far more damaging than a generic redirect elsewhere in the site given the financial context.

Attempt to upload an executable script disguised through double extensions, null byte injection, case variation, or trailing special characters to determine whether the extension filter can be bypassed while the server still executes the file according to its true type. Extension-only filtering is one of the most common and most bypassable file upload controls encountered in practice.

Where the server validates the uploaded file's declared Content-Type header or inspects file signature magic bytes, craft a file that presents a benign identifier while carrying malicious content, or forge the multipart Content-Type field directly, to determine whether either check alone is sufficient to block execution. Relying on client-supplied metadata for security decisions is inherently unreliable since both the header and, to a lesser extent, crafted magic bytes are attacker-controllable.

Construct a file that is simultaneously valid as an accepted format, such as an image, and as an executable script format, such as a PHP file, exploiting the fact that different parsers interpret the same byte stream differently. A successful polyglot passes strict content validation checks performed by an image library while still being executed as script code if the server later interprets the file by its stored extension.

Set the uploaded file's filename field to include parent-directory traversal sequences to determine whether the server writes the file outside its intended upload directory, potentially overwriting sensitive application files. Combined with a malicious file type, this can escalate a simple traversal bug directly into remote code execution by overwriting an executable application file.

Upload SVG files containing external entity declarations or embedded script tags to determine whether the server's image processing pipeline parses the XML content unsafely or serves the file in a way that lets a browser execute the embedded script. SVG's dual nature as both an image format and an XML document makes it a recurring vector for both XXE and XSS within upload features.

Upload a crafted archive whose internal entry names contain parent-directory traversal sequences, and determine whether the server's extraction logic writes those entries outside the intended extraction directory when unpacking the archive. Zip slip can let an attacker overwrite arbitrary files on the server purely through a file upload feature that performs server-side archive extraction.

Upload a small, deeply compressed archive or image file that expands to an extremely large size upon decompression, and monitor server memory and disk consumption during processing. A resource exhaustion attack through a tiny uploaded file can degrade or crash a server that does not enforce limits on decompressed output size.

Attempt to upload files far exceeding any documented size limit and submit a rapid succession of uploads to determine whether the server enforces per-file size caps and reasonable rate limits before consuming excessive storage or bandwidth. Missing size enforcement can allow storage exhaustion attacks even without any content-based exploit.

Determine whether uploaded files are stored under a predictable naming scheme, such as sequential IDs or the original filename unchanged, which would let an attacker guess or enumerate the location of files uploaded by other users. Predictable storage paths combined with weak or absent access control on the file-serving endpoint can expose private uploads to unauthorized parties.

Confirm that private or user-scoped uploaded files require proper authorization to retrieve, rather than being served directly and publicly from a static file path with no ownership check. A file upload feature that stores content securely but serves it without access control still fully exposes user data.

Upload images or documents containing embedded metadata such as GPS coordinates, author names, or device identifiers, and check whether that metadata is stripped before the file is made available to other users. Leaving metadata intact can leak personal information about the uploader well beyond the visible file content itself.

Check whether uploaded files, especially user-supplied HTML or SVG content, are served with headers that force a download or a safe rendering context rather than allowing the browser to render them inline within the application's own origin. Serving user-controlled content inline from the application's own domain effectively grants that content the same script execution trust as the application itself.

Where the platform advertises antivirus or malware scanning on uploaded files, test whether obfuscation, encryption, or splitting techniques allow a malicious payload to pass the scan undetected. Confirming a scanning bypass is important context even though the underlying finding might otherwise be treated as fully mitigated by the platform's stated control.

Where a file is scanned asynchronously after upload, attempt to access or execute the file during the brief window before scanning completes, since some implementations make the file available immediately and only remove it after the fact if flagged. A race condition here can let a malicious file be retrieved or executed before any protective scan has a chance to act.

Set the uploaded filename to include HTML, script, or command injection payloads and check whether the filename is later rendered unsanitized in a file listing page, included in a server-side command, or reflected into an HTTP header when the file is served. A filename field is easy to overlook as an injection point since testers tend to focus on the file content rather than its name.

Where uploaded files are processed by an image resizing, document conversion, or media transcoding library, test crafted malformed files that target known parser weaknesses in that specific library category, since these processing pipelines run with server-side privileges and often accept a wide range of complex, hard-to-fully-validate input formats. Even when direct upload-and-execute vectors are blocked, a vulnerable processing library invoked on the uploaded file can independently lead to server compromise.

Compile every endpoint referenced across official documentation, mobile app binaries, JavaScript bundles, and historical archives to find shadow or deprecated API versions that may still be reachable and less rigorously maintained than the current documented surface. Testing only the documented, actively promoted API version misses a significant share of real-world API vulnerabilities.

Where an API exposes multiple version paths such as v1 and v2, test whether the older version remains active and whether security fixes applied to the current version were also backported to it. Deprecated API versions are frequently left running for backward compatibility while receiving no further security maintenance.

Systematically request every resource type using an identifier belonging to a different account while authenticated as another user, applying the same object-level authorization testing performed against the web frontend to every raw API endpoint directly. APIs are especially prone to this issue since a mobile or single-page application frontend might correctly hide unauthorized data in its UI while the underlying endpoint still returns it to any caller who asks directly.

Compare the full raw JSON response returned by an endpoint against what the frontend actually displays, checking for additional fields such as internal flags, other users' partial data, or sensitive attributes that were only filtered out at the display layer rather than withheld by the API itself. Relying on the frontend to hide sensitive fields rather than restricting them server-side means anyone calling the API directly still receives the full unfiltered response.

Send a high volume of requests to sensitive endpoints such as login, password reset, OTP verification, and data export to determine whether rate limiting is enforced, and if so, whether it can be bypassed through header rotation, distributed source IPs, or alternate endpoint aliases. Missing rate limiting compounds the severity of numerous other findings, from brute-forcing to resource exhaustion.

Systematically add extra JSON fields to update and create requests across the entire API surface, not just the flows already covered in authorization testing, checking whether any endpoint silently binds unexpected fields to internal object properties. APIs frequently expose many more create and update endpoints than the frontend UI surfaces, so a comprehensive pass across the full endpoint list is necessary.

Attempt to call administrative or privileged API operations, such as user management or configuration endpoints, using a low-privileged account's credentials, since APIs frequently expose the full set of backend operations regardless of the calling client's actual role. This mirrors vertical privilege escalation testing but applies it directly and exhaustively across the raw API operation list.

Where introspection is enabled, extract the complete schema to identify every type, field, query, and mutation, including ones never called by the current frontend, then prioritize testing around unused or administrative-sounding operations. A schema dump effectively hands over full API documentation for free, dramatically accelerating targeted testing.

Submit a single request containing many aliased duplicate queries or deeply nested fields to determine whether the server enforces query complexity, depth, or batching limits before executing potentially expensive resolver logic many times over in one round trip. Unrestricted batching can be used to bypass simple per-request rate limiting since the entire attack fits inside a single HTTP request.

Explicitly test every mutation for proper authorization independent of how queries are protected, since mutation and query resolvers are often implemented as separate code paths that can diverge in how consistently access control middleware is applied. A well-protected read path does not guarantee the corresponding write path received the same scrutiny.

Beyond the general HTTP method testing done during authorization review, specifically verify REST resource endpoints correctly restrict which verbs are semantically appropriate, such as ensuring a read-only resource never accepts a DELETE or PUT regardless of authentication state. REST APIs that map verbs loosely to backend logic can expose destructive operations through methods a client was never expected to use.

Identify separate hosts serving internal, partner, or beta API variants of the same product and test whether these copies enforce the same security controls as the primary production API. Multiple parallel API deployments frequently drift out of sync in terms of patch level and configuration hardening.

Where the application integrates with an external API and consumes its response data, check whether that response data is trusted and processed without the same validation applied to direct user input, such as rendering it unsanitized or using it in a server-side query. Data originating from a third-party service is still externally influenced input and deserves the same scrutiny as data supplied directly by the end user.

Manipulate pagination limit, offset, and sort parameters for unexpectedly large page sizes, negative values, or injection payloads to test both potential denial of service through oversized result sets and injection into the underlying query construction. Pagination parameters are handled by nearly every list endpoint yet are frequently validated less carefully than primary business parameters.

Request alternate representations of an API resource through the Accept header, such as XML instead of JSON, to check whether a less-tested response serialization path introduces its own vulnerabilities like XXE or inconsistent field filtering. Secondary output formats often receive less security review than the primary, most commonly used format.

Check whether authentication is accepted via a query string parameter rather than a header, since URL-embedded credentials are far more likely to be logged in server access logs, browser history, and referrer headers sent to third-party resources. Even if headers are also supported, accepting a query-string credential undermines protections built around header-only authentication.

Where an API supports idempotency keys to prevent duplicate processing of retried requests, test whether reusing a key across different request bodies is properly rejected, and whether omitting the key entirely allows an operation to be repeated indefinitely. Idempotency mechanisms that are not strictly scoped and validated can themselves become a vector for either duplicate financial transactions or a race-condition-adjacent replay issue.

Check whether the CORS configuration is applied uniformly across every API endpoint or whether some routes, especially newer or less common ones, apply a more permissive policy than the rest of the API. Inconsistent CORS enforcement across a large API surface is common since the policy is sometimes configured per-route rather than globally.

Submit the same parameter name multiple times in a single request with differing values to observe which value the backend ultimately uses, since inconsistent parameter parsing between a front-facing proxy and the backend API can be exploited to smuggle a second, attacker-controlled value past validation logic applied only to the first occurrence. This technique can bypass filters that check only the first or last instance of a repeated parameter.

Trigger malformed queries and internal resolver errors to see whether the GraphQL error response includes stack traces, internal file paths, or database error text rather than a generic client-safe error message. Verbose GraphQL errors are a frequent and easily triggered source of information disclosure about backend implementation details.

Intercept checkout and cart requests to determine whether price, discount, or quantity values are trusted from the client rather than recalculated server-side from an authoritative product catalog. Any pricing logic that trusts client-supplied values can be trivially manipulated to purchase goods or services below their intended cost.

Attempt to apply a single-use coupon multiple times, stack mutually exclusive discounts, or apply a coupon intended for a different product category to see whether server-side validation actually enforces the intended usage rules. Discount logic is frequently implemented with client-side assumptions about legitimate usage that do not hold up against direct API manipulation.

Attempt to complete a multi-step process, such as an approval chain or a checkout flow, out of the expected order by directly calling later-stage endpoints, since applications often assume the frontend will always enforce the correct sequence rather than validating state transitions server-side. Bypassing an approval or verification step this way can let an attacker skip a control that was central to the application's intended trust model.

Send multiple concurrent requests to an operation that checks and then updates a limited resource, such as a coupon redemption count, an inventory count, or a rate limit counter, to see whether the check-then-act sequence can be exploited to exceed the intended limit before the counter updates. Race conditions exploit the gap between when a condition is checked and when the corresponding state change is committed.

Fire simultaneous requests against wallet, balance-transfer, or refund endpoints to determine whether the application correctly serializes access to the underlying account balance or allows the same funds to be spent, transferred, or refunded more than once. Financial operations are the highest-impact target category for race condition testing given the direct monetary consequence of a successful exploit.

Submit negative numbers, zero, and extremely large values into quantity, amount, and duration fields to determine whether the application's business logic correctly rejects values outside a sane range or whether it silently processes them in unintended ways, such as a negative quantity effectively crediting the attacker's account. Numeric boundary handling is frequently validated for format but not for business-meaningful range.

Attempt to replay a request that represents an action meant to happen only once, such as claiming a signup bonus, redeeming a referral reward, or submitting a survey for a reward, to check whether the server actually enforces a one-time constraint tied to the user's account rather than relying on the frontend hiding the option after first use. Actions with a tangible reward attached are natural targets for this kind of abuse.

Determine whether referral rewards can be claimed by referring accounts the attacker also controls, such as freshly created throwaway accounts, and whether any velocity or identity checks meaningfully limit this kind of farming at scale. Referral program abuse can result in direct financial loss when rewards translate into real currency, credits, or physical goods.

Where access to premium content, downloads, or feature-gated functionality is determined by a client-visible parameter such as a plan tier or entitlement flag, test whether altering that parameter grants access without an actual corresponding purchase or subscription upgrade. Entitlement checks performed against client-supplied state rather than a server-side subscription record are a recurring subscription-bypass pattern.

Identify business rules enforced only in client-side JavaScript, such as maximum transaction amounts or eligibility checks, and confirm whether the same rule is independently enforced server-side when the client-side check is bypassed entirely. Any business rule that exists only in the browser is not actually enforced at all from a security perspective.

Evaluate whether the registration flow imposes meaningful friction, such as verified email ownership or device fingerprinting, against large-scale automated account creation used to farm promotions, bypass per-account limits, or manipulate rating and review systems. Weak account creation friction magnifies the impact of many other business logic flaws that are normally bounded by a one-account-per-person assumption.

Where the application performs currency conversion or percentage-based calculations, test edge-case inputs designed to produce favorable rounding errors that compound into a meaningful financial gain over repeated transactions. Rounding-based logic flaws are subtle and typically only exploitable at scale, but can be very difficult to detect after the fact since each individual transaction appears legitimate.

Look for cases where a validation decision, such as confirming stock availability or verifying a promotional window is still active, is made well before the corresponding action is executed, leaving a window during which the underlying condition could change without being rechecked. This is a broader pattern than pure concurrency-based races and can be exploited even with sequential, non-parallel requests if the time gap is large enough.

Diagram the intended states an object such as an order or a support ticket can move through, then attempt to force a transition that should not be reachable from the object's current state, such as marking an unpaid order as shipped. Applications rarely validate every possible state transition explicitly, often only guarding against the transitions exercised by the normal UI flow.

Where the application accepts webhook callbacks from a payment processor or third-party service to trigger state changes such as marking an order as paid, verify that incoming events are authenticated with a signature and that replaying a previously valid webhook payload does not trigger the associated action a second time. An unauthenticated or replayable webhook endpoint can let an attacker directly forge events like fraudulent payment confirmations.

Simulate multiple simultaneous checkout attempts for the last remaining unit of limited-quantity stock to determine whether the reservation and decrement logic correctly serializes access, preventing the same unit from being sold to more than one buyer. This combines race condition and business logic testing specifically around inventory-constrained purchase flows common in e-commerce and ticketing platforms.

Check whether the server still accepts connections using outdated protocol versions rather than requiring a modern, currently recommended TLS version. Supporting legacy protocol versions widens the pool of clients that can be downgraded into using a weaker, more attackable connection.

List every cipher suite the server is willing to negotiate and flag any that use weak key lengths, lack forward secrecy, or rely on broken algorithms. A server that still offers weak ciphers as a fallback option can be coerced into using them by a network-positioned attacker even if strong ciphers are also available.

Verify the certificate is issued by a trusted certificate authority, has not expired, correctly chains to a trusted root, and matches every hostname it is served under, including all subject alternative names. A certificate mismatch or an expired certificate undermines user trust indicators and can train users to ignore legitimate browser warnings.

Load pages served over HTTPS and check whether any subresource, such as a script, stylesheet, or image, is fetched over plain HTTP, which browsers may block or warn about but which still represents an integrity gap in the page's overall trust chain. Mixed content involving active resources like scripts is particularly serious since it allows a network attacker to inject code into an otherwise HTTPS-protected page.

Check whether the server sends an HSTS header with an adequate max-age directive, and whether HTTP requests are ever served without an immediate redirect to HTTPS. Without HSTS, a user's very first request to a domain, or any request made over an untrusted network, remains exposed to protocol downgrade and interception attacks.

Determine whether a wildcard certificate is used more broadly than necessary, covering subdomains with significantly different trust levels or operated by different teams, since compromise of any one subdomain's private key material could be used to impersonate the entire wildcard scope. Scoping certificates tightly limits the blast radius of a single compromised private key.

Run protocol-level fuzzing and known memory-safety check scripts against the TLS implementation in use to detect heap memory disclosure issues that can leak private keys, session data, or other sensitive in-memory content directly from the TLS stack. Confirmed memory disclosure in a TLS library is catastrophic since it can expose the server's private key material itself.

Check whether the server supports client-initiated renegotiation without the security extension that binds the renegotiated session to the original one, which historically enabled request injection attacks during the renegotiation handshake. Disabling client-initiated renegotiation entirely removes this attack surface with minimal compatibility impact on modern clients.

Check whether TLS-level compression is enabled, since combining compression with encryption can allow an attacker who can influence part of the plaintext to infer secret values, such as session tokens, by observing changes in compressed output size across repeated requests. This class of attack requires the attacker to control some portion of the request alongside the secret, but disabling compression removes the risk entirely regardless of that precondition.

Request directory paths without an index file present to check whether the server responds with an auto-generated file listing rather than a 403 or 404, since directory listing can reveal the existence of backup files, configuration files, or other resources not otherwise linked from the application. This is a low-effort check that occasionally surfaces significant unintended exposure.

Look for default landing pages, sample applications, or setup wizards shipped with common web servers and frameworks that were never removed after deployment. Default pages sometimes expose version information or, in the case of an unfinished setup wizard, allow an attacker to complete initial configuration and gain administrative control.

Where the application sits behind a reverse proxy, load balancer, or CDN, craft requests with ambiguous Content-Length and Transfer-Encoding headers to determine whether the front-end and backend server disagree on where one request ends and the next begins. A confirmed smuggling primitive can be used to hijack another user's request, bypass front-end security controls, or poison a shared cache.

Verify the server's system clock is properly synchronized, since significant drift can undermine time-based security mechanisms such as token expiry, one-time password validity windows, and TLS certificate validity checks. This is a low-severity operational item but worth confirming since it silently weakens several time-dependent controls at once.

Trigger common server errors such as 404 and 500 responses and check whether the resulting error page reveals the exact web server or framework version, which could be used to look up known weaknesses in that specific release. Custom, generic error pages prevent this class of low-effort information leakage.

Cross-reference every identified library, framework, and server software version against its current supported release line to flag components that are past end-of-life or several versions behind current, since these no longer receive security patches from their maintainers. Running unsupported software accumulates unpatched weaknesses over time even without a single specific known issue being confirmed.

Probe for common configuration file names and environment variable files at the web root that may contain database credentials, API keys, or internal service URLs. Configuration files are sometimes accidentally deployed alongside application code rather than being excluded from the web-accessible directory.

Where the server supports newer HTTP protocol versions, test protocol-specific edge cases such as header handling differences and downgrade paths to HTTP/1.1 at the backend, since these newer protocols introduce their own distinct parsing behavior that can diverge from HTTP/1.1 assumptions baked into other parts of the infrastructure. Multi-protocol environments create additional opportunities for the same class of parser-disagreement issues seen in classic request smuggling.

Simulate a network position capable of interfering with the initial handshake to determine whether a client can be coerced into negotiating a weaker protocol version or cipher than it would otherwise prefer, when the server still supports that weaker option as a fallback. Removing legacy fallback support entirely is the most reliable mitigation, since a downgrade attack cannot succeed if the weaker option was never available to negotiate in the first place.

Send requests with an attacker-controlled Origin header to sensitive, session-authenticated endpoints and check whether the response reflects that origin back in Access-Control-Allow-Origin, especially in combination with Access-Control-Allow-Credentials set to true. This combination lets any malicious website read authenticated response data on behalf of a visiting victim, effectively defeating the same-origin policy the browser is meant to enforce.

Send a request with an Origin header value of null, which browsers send in certain sandboxed contexts such as a locally rendered HTML file or a sandboxed iframe, and check whether the server allows it. An attacker can trivially generate a request carrying the null origin from a sandboxed iframe hosted anywhere, so accepting it as trusted is nearly equivalent to accepting any origin.

Where the CORS policy allows any subdomain of the main domain via a suffix or wildcard match, evaluate whether a single vulnerable or attacker-registrable subdomain could be used to satisfy that policy and read cross-origin data from the main application. Broad subdomain trust in CORS policy inherits the security posture of every subdomain, including ones with weaker controls or ones vulnerable to takeover.

Attempt to load sensitive pages, particularly ones that perform a state-changing action with a single click, inside an iframe on an external page to determine whether the browser blocks the framing or whether the page renders normally and remains interactive. A successful frame load without protection lets an attacker overlay deceptive UI elements to trick a victim into unknowingly clicking a genuine but invisible control on the target site.

Check whether X-Frame-Options or the frame-ancestors CSP directive is applied uniformly across every state-changing page rather than only on a few high-visibility ones such as the login page, since a single unprotected sensitive page is enough to carry out a clickjacking attack. Partial coverage across a site gives a false sense of protection while leaving specific pages fully exploitable.

Analyze the full CSP directive set for overly permissive script and style sources, missing directives that leave a default-src fallback too broad, and use of unsafe-inline or unsafe-eval that undermines script injection protection. A present but weak CSP is common and provides substantially less protection than its presence alone might suggest during a quick review.

Confirm the header is present and set to nosniff on all responses, particularly ones serving user-uploaded or user-influenced content, since without it a browser may reinterpret a response's content type based on its content rather than its declared header, potentially causing a file intended to be treated as plain text to be executed as script or HTML. This is a lightweight, broadly compatible header that closes off an entire class of content-type confusion attacks.

Check whether the site sets an appropriately restrictive referrer policy to prevent full URLs, including sensitive query string parameters or path segments, from leaking to third-party sites through the Referer header on outbound navigation or resource requests. A missing or overly permissive referrer policy can leak session tokens or other sensitive URL parameters to any external domain linked from the page.

Check whether powerful browser features such as camera, microphone, geolocation, and payment request access are explicitly restricted through a Permissions-Policy header, particularly for pages that embed third-party content. Unrestricted feature access can be abused by a compromised or malicious embedded third-party script to access sensitive device capabilities without the user's expectation.

Confirm that pages displaying sensitive personal or session-specific data instruct browsers and intermediate caches not to store the response, since improperly cached sensitive pages can be exposed to a subsequent user of the same shared computer or leak into a misconfigured shared proxy cache. This is especially important for pages reachable right after logout or on shared, publicly accessible devices.

Identify headers or parameters that influence the response but are not included in the cache key, then craft a malicious response using one of these unkeyed inputs and confirm whether the poisoned response gets cached and subsequently served to other users. A successful cache poisoning attack can deliver a single crafted malicious response to a large number of victims who simply request the affected cached URL normally.

For every cloud storage bucket or blob container the application references, verify whether it is publicly listable, publicly writable, or otherwise misconfigured beyond what is needed for the application's actual functionality. A writable bucket used to serve application assets can be used to distribute malicious content directly to every visitor of the site.

Where cloud credentials or a service role can be identified as belonging to the application, such as through a leaked key or an SSRF-retrieved metadata token, evaluate whether the associated permissions are broader than what the application's actual functionality requires. An overprivileged service identity turns any single credential leak into a much larger blast radius across the surrounding cloud environment.

Specifically test any embeddable widget the application exposes for third-party integration, such as a payment or comment widget, for clickjacking protection, since these widgets are explicitly designed to be framed by other sites and therefore need carefully scoped, intentional framing rules rather than a blanket allow or a forgotten default. A widget meant for controlled third-party embedding is a very different risk profile from an accidental lack of frame protection on the main application.

Check whether scripts and stylesheets loaded from third-party origins, such as a CDN, include an integrity attribute that lets the browser verify the fetched content has not been tampered with. Without Subresource Integrity, a compromise of the third-party host can silently deliver malicious code to every visitor of the including page.

Check the value of the legacy X-XSS-Protection header if present, ensuring it is not configured in a way that could be leveraged by an attacker to selectively disable a browser's now-deprecated built-in reflected XSS filtering in older browser versions still in use by some of the application's user base. While largely superseded by CSP in modern browsers, verifying this legacy header is not misconfigured remains a quick, low-cost check.

Verify that the Access-Control-Allow-Methods and Access-Control-Allow-Headers returned in a preflight response are scoped tightly to what the application actually needs, rather than reflecting whatever the requesting client asked for in its preflight request. Overly permissive preflight responses can allow a wider range of cross-origin request types than the application's functional CORS policy was ever intended to permit.

Document the exact sequence of requests, parameters, and account states needed to reproduce the finding from scratch, assuming the reader has no prior context on the target. A report that a triager cannot reproduce on the first attempt is far more likely to be marked as informative or closed without action, regardless of the vulnerability's real severity.

Explain what a real attacker could actually achieve by exploiting the finding in terms the program owner cares about, such as data exposed, accounts affected, or financial consequence, rather than restating the technical mechanism alone. A well-argued impact statement is frequently the deciding factor in how a triager prioritizes and rewards a submission.

Save full raw HTTP requests and responses, annotated screenshots, and for complex or timing-sensitive issues a short screen recording that demonstrates the exploit end to end. Comprehensive evidence reduces back-and-forth with the triage team and protects against later disputes over whether the finding was genuinely reproducible.

Reference a standard scoring framework such as CVSS to justify the severity rating assigned to the finding, walking through the relevant metrics like attack vector, privileges required, and impact scope rather than asserting a severity level without explanation. A justified severity score gives the triage team a clear basis to agree or push back with specifics rather than negotiating from a purely subjective starting point.

Recommend a concrete fix appropriate to the underlying root cause, such as adopting parameterized queries for an injection finding or adding server-side re-validation for a broken access control finding, rather than a generic suggestion to 'sanitize input' or 'add validation.' Specific guidance shortens the fix cycle and demonstrates a deeper understanding of the vulnerability beyond simply triggering it.

Before submitting, re-verify the affected asset was within the program's declared scope and that no explicitly prohibited technique, such as denial-of-service testing or social engineering, was used to obtain the finding. Submitting an otherwise excellent finding that violates scope or rules of engagement can result in the report being rejected outright and can damage the researcher's standing with the program.

Check the program's disclosed report history and any public vulnerability disclosure timeline for the same or a closely related finding before submitting, since duplicate reports are typically not rewarded and searching first saves both the researcher's and the triage team's time. Some platforms expose a searchable list of previously disclosed reports specifically to help researchers avoid this.

Where a full compromise depends on combining multiple individually low-impact findings, present them together as one connected attack chain with a unified proof of concept, rather than submitting each piece separately without context. A clearly narrated chain often more accurately reflects real-world risk and helps the triage team appreciate a severity level that no individual component would justify on its own.