eWPT key terms

The phase of a web assessment where you collect data about the target's domains, hosts, technologies, and people without yet attacking. It includes passive sources such as search engines and certificate logs, and active probing such as DNS queries and banner grabbing.

Gathering information about a target purely from third-party sources, so no packet ever reaches the target's own systems. Examples include WHOIS records, certificate transparency logs, search engine results, and archived pages.

Directly interacting with target infrastructure to learn about it, for example resolving subdomains, sending HTTP requests, or scanning ports. Because it generates traffic and logs, it requires explicit authorization within the engagement scope.

Open-source intelligence: information lawfully collected from publicly available sources such as social media, job postings, code repositories, and public documents. In web testing it often reveals employee names, internal tooling names, email formats, and leaked credentials.

Using advanced search operators (such as site:, inurl:, filetype:, intitle:) to surface pages, documents, or exposed files a site owner did not intend to advertise. It is a passive technique useful for finding login portals, backups, and directory listings.

Discovering hostnames under a target's parent domain, often via certificate transparency logs, DNS brute forcing, search engines, or virtual host probing. Forgotten subdomains frequently run outdated software or expose staging and admin interfaces.

Public, append-only records of issued TLS certificates. Because every publicly trusted certificate is logged, querying these logs can reveal subdomains and internal hostnames the organization never published in DNS.

A mechanism (AXFR) that replicates a DNS zone from a primary to a secondary server. If misconfigured to allow anyone, it hands over the full list of hostnames and IP addresses in the zone in one query.

Querying DNS records (A, AAAA, MX, TXT, NS, CNAME, SOA) to map a domain's infrastructure and ownership. TXT records in particular can reveal SPF, DMARC, and third-party service verification entries.

Sending requests with different Host header values to one IP address to identify websites served by name-based virtual hosting. It uncovers sites that share an IP but have no public DNS record.

Probing TCP or UDP ports to determine which services are listening and reachable. Results guide later testing, for example finding an exposed database, an alternate web port, or a forgotten management interface.

Identifying the software and version behind an open port by analyzing banners, response patterns, and protocol behavior. Accurate versions let a tester check for known vulnerabilities and default configurations.

Determining the frameworks, servers, languages, and libraries a web application uses, typically from headers, cookies, error pages, file extensions, and static asset paths. It narrows which vulnerability classes and known CVEs are plausible.

Identifying web technologies by matching signature patterns, such as specific script paths, cookie names, or HTML comments, against a fingerprint database. Tools automate this, but manual verification of a few signatures improves confidence.

Reviewing robots.txt disallow entries and sitemap files to learn which paths the owner wants hidden from crawlers. These often point to admin panels, backups, or staging areas worth testing.

A web server feature that returns an index of files in a folder when no default page exists. It can expose backups, source code, uploads, and configuration files that were never meant to be browsable.

Requesting paths and files that are not linked in the application, such as /admin, /backup.zip, or /.git/, to find resources protected only by obscurity. It relies on wordlists and status-code comparison rather than exploitation.

Systematically enumerating endpoints, parameters, and files using wordlists and response analysis. Testers compare status codes, response lengths, and timing to distinguish real resources from soft-404 pages.

Automated sending of payload lists to parameters, paths, or headers and analyzing responses for anomalies. Effective fuzzing requires filtering false positives, such as identical error pages, before drawing conclusions.

A flaw where untrusted input is interpreted as code or commands by a downstream component, such as a database, shell, or template engine. The fix is to separate data from instructions via parameterization, not to filter characters.

Supplying crafted input that alters a database query's structure, letting an attacker read, modify, or delete data. Common proof techniques include boolean logic changes, UNION-based extraction, and time-based blind inference.

SQL injection where query output is not returned directly, so the attacker infers data from true/false response differences or response delays. Boolean-based and time-based variants are the classic forms.

An injection where the payload is stored safely at first and only becomes dangerous when later used in a query or command without proper handling. Testing requires tracing data flows, not just replaying input on the same page.

Injecting operating system command syntax into input that is passed to a shell, allowing arbitrary command execution on the server. Chaining with shell metacharacters such as semicolons or pipes is a common verification method.

Injecting script into pages viewed by other users, which executes in their browser and can steal sessions or perform actions as them. Variants are reflected, stored, and DOM-based, each with different sources and sinks.

XSS where the payload is persisted server-side, such as in a comment or profile field, and executes for every viewer of that content. It is generally more severe because it needs no lure or crafted link.

XSS that occurs entirely in client-side JavaScript when attacker-controlled data from a source such as location.hash reaches a dangerous sink like innerHTML. The server response may be unchanged, so server-side filters miss it.

An HTTP response header that restricts which script, style, and other resource sources a page may load. A strong CSP can block or limit XSS impact, while weak policies with unsafe-inline or wildcards provide little protection.

Forcing a logged-in victim's browser to send a state-changing request to a site that trusts the browser's ambient credentials. Defenses include unpredictable anti-CSRF tokens and SameSite cookie attributes.

A cookie setting (Strict, Lax, or None) that controls whether the browser sends the cookie on cross-site requests. Lax permits top-level navigations, so it reduces but does not eliminate CSRF risk.

Making the server issue a request to a URL the attacker chooses, potentially reaching internal services, cloud metadata endpoints, or localhost-only admin panels. It is especially dangerous in cloud environments with instance metadata access.

Accessing another user's records by changing an identifier such as a numeric ID in a request, because the server checks authentication but not ownership. It is a form of broken access control and is common in APIs.

Failures that let a user act outside their intended permissions, including missing authorization checks, forced browsing to privileged pages, and privilege escalation through parameter tampering. It consistently ranks among the most critical web risk categories.

Gaining permissions or access levels beyond those granted, either by exploiting a flaw in the application (horizontal or vertical) or by abusing the host operating system after code execution. In web tests it usually means reaching admin functionality.

A flaw where user input controls which file a script includes. Local file inclusion reads server files, while remote file inclusion loads code from an attacker-controlled URL; both can lead to code execution.

Using sequences such as ../ to escape an intended directory and read or write files outside it. Encoded and doubled variants are used to bypass naive filters.

Weak validation of uploaded files that allows executable content, such as a script or a web shell, to be stored and later run by the server. Bypasses include alternate extensions, content-type spoofing, and polyglot files.

A small script uploaded to a compromised server that provides remote command execution or file management through HTTP requests. It is a common persistence mechanism after a file upload or inclusion flaw is exploited.

The ability to run arbitrary code or commands on the target host, usually the highest-impact finding in a web assessment. It typically results from injection, deserialization, file inclusion, or upload flaws, and must be demonstrated carefully with approval.

A flaw where untrusted serialized data is reconstructed into objects, letting an attacker control object state or trigger gadget chains that execute code. It appears in Java, PHP, Python, and .NET applications and often requires chained classes.

Gaining access without valid credentials by exploiting logic flaws, weak token validation, default accounts, or injection in login queries. It differs from credential guessing because no valid password is required.

Systematically trying many credential combinations against a login or token endpoint. Effective testing checks for rate limiting, account lockout, and predictable reset tokens rather than simply running a large password list.

Weaknesses in how sessions are created, stored, or invalidated, such as predictable tokens, missing expiry, or tokens not rotated after login. These allow session hijacking or fixation attacks.

HTTP response headers that instruct browsers to enforce protections, including Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, and X-Content-Type-Options. Missing or weak headers are reported as hardening gaps, not standalone exploits.

Manipulating the Host header so the application generates links, caches entries, or routes requests to attacker-chosen destinations. It can enable password reset poisoning, cache poisoning, or access to internal virtual hosts.

Causing a shared cache to store a malicious response that is then served to other users, often by exploiting unkeyed inputs such as headers. Impact can range from defacement to script execution for all visitors.

A technique for confirming a vulnerability by making the target contact an external server you control, for example via DNS or HTTP callbacks. It is valuable for blind injection and SSRF where in-band responses reveal nothing.

A minimal, reproducible demonstration that a vulnerability is real, such as a request and response pair or a short script. A good PoC shows impact without causing unnecessary damage or data loss.

Assigning severity to a finding using factors such as exploitability, impact, and exposure, often via a standardized scoring system. Ratings help the client prioritize remediation and justify the report's conclusions.

The structured report entry for one vulnerability, containing title, affected asset, severity, description, reproduction steps, evidence, impact, and remediation advice. Clear, non-alarming language and exact request details make it actionable for developers.

Specific, practical advice on fixing a finding, ideally at the root cause rather than the symptom, with references to secure coding patterns or configuration changes. Vague advice such as "sanitize input" is not acceptable in a professional report.

The written agreement defining scope, allowed techniques, testing windows, escalation contacts, and prohibited actions for an engagement. It protects both tester and client and should be confirmed before any active testing begins.

The explicit list of domains, IP ranges, applications, and accounts that may be tested, plus anything excluded. Testing outside scope, even accidentally, can be unlawful and must be avoided and reported.

Reporting a vulnerability privately to the owner and allowing reasonable time to fix it before any public discussion. It balances the public's need to know with the risk of exposing unfixed systems to attackers.