🔍 WSTG-INFO: Information Gathering

OWASP Web Security Testing Guide v4.2

By FixTheVuln Team Sources: OWASP WSTG v4.2
← OWASP WSTG Guide

Information Gathering forms the foundation of web security testing. Before attempting to find vulnerabilities, testers must understand the target's technology stack, infrastructure, and exposed assets. This category covers techniques ranging from passive search engine reconnaissance to active fingerprinting of web servers and applications. Effective information gathering reduces wasted effort during later testing phases and often reveals low-hanging fruit like exposed admin panels, leaked credentials in source code, or misconfigured servers. For cert candidates, mastering this phase is essential because every penetration testing methodology starts here.

Difficulty: Beginner 10 test cases

OWASP Top 10 Mapping

This testing category relates to the following OWASP Top 10 2021 categories:

A05

Quick Reference

Test ID Name CWEs Difficulty
WSTG-INFO-01Search Engine DiscoveryCWE-538Beginner
WSTG-INFO-02Web Server FingerprintingCWE-200Beginner
WSTG-INFO-03Webserver Metafiles ReviewCWE-538, CWE-200Beginner
WSTG-INFO-04Application EnumerationCWE-200Beginner
WSTG-INFO-05Webpage Content ReviewCWE-200, CWE-615Beginner
WSTG-INFO-06Application Entry PointsCWE-200Beginner
WSTG-INFO-07Execution Path MappingCWE-200Beginner
WSTG-INFO-08Framework FingerprintingCWE-200Beginner
WSTG-INFO-09Web Application FingerprintingCWE-200Beginner
WSTG-INFO-10Architecture MappingCWE-200Beginner

Detailed Test Cases

WSTG-INFO-01: Search Engine Discovery

Beginner

This test uses search engines to discover publicly indexed information about a target, including sensitive files, exposed directories, and cached content. Search engine operators (Google Dorks) can reveal login pages, error messages, and documents that were never intended to be public.

Why it matters: Organizations often unknowingly expose sensitive information that gets indexed by search engines. Attackers routinely use search engine dorking as a zero-cost, zero-risk first step to find exploitable data.

What to Check

  • Search for indexed admin panels and login pages using site: and inurl: operators
  • Look for exposed sensitive file types (PDFs, spreadsheets, configuration files) with filetype: operator
  • Check for cached versions of pages that may have been removed
  • Search for error messages or debug output that reveals technology stack details
  • Review robots.txt entries that might point to hidden directories
Tools: Google Dorking Bing Search Shodan DuckDuckGo Wayback Machine
CWE-538

WSTG-INFO-02: Web Server Fingerprinting

Beginner

Web server fingerprinting identifies the type and version of the web server software handling requests. This is done by analyzing HTTP response headers, default error pages, and server behavioral differences between implementations like Apache, Nginx, and IIS.

Why it matters: Knowing the exact web server version helps testers search for known vulnerabilities and misconfigurations specific to that software. It also reveals whether the server is running outdated or end-of-life software.

What to Check

  • Examine the Server header in HTTP responses for version information
  • Analyze default error pages (404, 500) for server-specific formatting
  • Check HTTP response header ordering which differs between server implementations
  • Test how the server responds to malformed requests or unusual HTTP methods
  • Look for server-specific default files and directories
Tools: Nmap Netcraft WhatWeb curl httprint
CWE-200

WSTG-INFO-03: Webserver Metafiles Review

Beginner

Webserver metafiles like robots.txt, sitemap.xml, and security.txt can leak information about the application structure. These files often reveal hidden directories, admin paths, and internal endpoints that are not intended for public access.

Why it matters: Metafiles are publicly accessible by design but frequently contain references to sensitive areas of the application. Attackers use these files to quickly map out restricted areas and prioritize their testing efforts.

What to Check

  • Review robots.txt for Disallow entries that point to sensitive directories
  • Check sitemap.xml for URLs not linked from the main application
  • Look for security.txt in the .well-known directory for contact and policy information
  • Search for humans.txt, crossdomain.xml, and clientaccesspolicy.xml
  • Check for exposed .git, .svn, or .env files in the web root
Tools: curl Burp Suite wget Browser Developer Tools
CWE-538 CWE-200

WSTG-INFO-04: Application Enumeration

Beginner

This test identifies all applications hosted on a web server, including those on non-standard ports, virtual hosts, and subdomains. A single server often hosts multiple applications, some of which may be forgotten, unmaintained, or running vulnerable software.

Why it matters: Forgotten or shadow applications are a common attack vector because they often lack patching and monitoring. Finding all applications on a server reveals the complete attack surface that needs to be tested.

What to Check

  • Scan for applications running on non-standard ports
  • Enumerate virtual hosts using DNS records and brute-force techniques
  • Check for applications in common subdirectories (/admin, /portal, /api, /test)
  • Look for different applications served based on the Host header
  • Identify staging or development instances accessible from the internet
Tools: Nmap Gobuster ffuf Sublist3r Amass
CWE-200

WSTG-INFO-05: Webpage Content Review

Beginner

Reviewing webpage source code and content can reveal developer comments, internal IP addresses, API keys, debug information, and hidden form fields. This information is often left behind from development and provides valuable intelligence for attackers.

Why it matters: Developers frequently leave sensitive information in HTML comments, JavaScript files, and metadata that is invisible to regular users but easily found by anyone who views the source code. This leakage can expose internal infrastructure details or even credentials.

What to Check

  • Search HTML source for developer comments containing sensitive information
  • Look for hardcoded API keys, tokens, or credentials in JavaScript files
  • Check for internal IP addresses or hostnames in page source
  • Review hidden form fields for parameters that control server-side logic
  • Examine metadata in documents and images for author names and software versions
Tools: Burp Suite Browser Developer Tools grep LinkFinder
CWE-200 CWE-615

WSTG-INFO-06: Application Entry Points

Beginner

Identifying entry points means mapping every way data can enter the application, including URL parameters, form fields, HTTP headers, cookies, and API endpoints. Each entry point is a potential injection vector that needs to be tested in later phases.

Why it matters: Entry points define where user input interacts with application logic. Missing an entry point during testing means potentially missing a vulnerability. Thorough mapping ensures complete test coverage across the application.

What to Check

  • Map all URL parameters across GET and POST requests
  • Identify form fields including hidden inputs
  • Document HTTP headers that influence application behavior (Host, Referer, User-Agent)
  • List all cookie values and their purposes
  • Catalog API endpoints and their accepted input formats (JSON, XML, multipart)
Tools: Burp Suite OWASP ZAP Browser Developer Tools Postman
CWE-200

WSTG-INFO-07: Execution Path Mapping

Beginner

Mapping execution paths traces how data flows through the application from input to output, including all processing steps, database queries, and external service calls. This helps identify where input validation occurs and where it might be bypassed.

Why it matters: Understanding data flow reveals where trust boundaries exist and where input might bypass validation. Complex execution paths with multiple processing stages often contain logic errors that can be exploited.

What to Check

  • Trace how user input flows from entry point through processing to response
  • Identify trust boundaries where data crosses between components
  • Map multi-step processes like registration, checkout, or file upload workflows
  • Document conditional logic paths (error handling, edge cases, fallback behaviors)
  • Look for places where processed data is used in secondary operations
Tools: Burp Suite OWASP ZAP Browser Developer Tools Application source code review
CWE-200

WSTG-INFO-08: Framework Fingerprinting

Beginner

Framework fingerprinting identifies the web application framework (e.g., Django, Rails, Spring, Laravel) powering the target. This is accomplished by analyzing HTTP headers, cookie names, URL patterns, HTML structure, and error pages unique to each framework.

Why it matters: Each framework has known default configurations, common vulnerabilities, and specific attack patterns. Identifying the framework allows testers to focus on framework-specific issues and known CVEs rather than testing blindly.

What to Check

  • Analyze cookie names for framework-specific patterns (JSESSIONID for Java, PHPSESSID for PHP)
  • Check HTTP response headers for framework-specific identifiers (X-Powered-By, X-AspNet-Version)
  • Examine URL structures and routing patterns characteristic of specific frameworks
  • Look for default error pages, login screens, or admin panels with framework branding
  • Check for framework-specific files in predictable locations
Tools: Wappalyzer WhatWeb BuiltWith Burp Suite curl
CWE-200

WSTG-INFO-09: Web Application Fingerprinting

Beginner

This test identifies the specific web application or CMS in use, such as WordPress, Drupal, or a custom application. It goes beyond framework identification to determine the exact software product and version, including plugins and extensions.

Why it matters: Known applications have documented vulnerability databases, default credentials, and established exploitation techniques. Identifying the exact version allows testers to check for unpatched CVEs and known attack paths.

What to Check

  • Check for CMS-specific files (wp-login.php for WordPress, /administrator for Joomla)
  • Review HTML source for generator meta tags and version comments
  • Fingerprint installed plugins and extensions through their public-facing resources
  • Analyze JavaScript and CSS file paths for application-specific naming conventions
  • Compare page structure and behavior against known application signatures
Tools: WPScan CMSMap Wappalyzer Nikto Nmap NSE scripts
CWE-200

WSTG-INFO-10: Architecture Mapping

Beginner

Architecture mapping builds a complete picture of the target's infrastructure including web servers, application servers, databases, load balancers, CDNs, WAFs, and third-party services. Understanding the full architecture reveals how components interact and where security boundaries exist.

Why it matters: Modern applications rely on complex architectures with multiple components. Knowing the full architecture helps testers identify weak links, bypass security controls at component boundaries, and understand the impact of potential vulnerabilities.

What to Check

  • Identify reverse proxies, load balancers, and CDN providers from response headers
  • Detect Web Application Firewalls (WAFs) that may filter attack payloads
  • Map backend databases and storage services from error messages and behavior
  • Document third-party integrations and API dependencies
  • Identify different environments (production, staging, development) accessible from the internet
Tools: Nmap Burp Suite wafw00f traceroute Shodan
CWE-200

Relevant Certifications

The following certifications cover information gathering concepts:

Security+CEHOSCPGPEN

Frequently Asked Questions

What is WSTG-INFO and why is information gathering important in security testing?

WSTG-INFO is the Information Gathering category of the OWASP Web Security Testing Guide. It covers techniques for collecting data about a target application before active testing begins. This phase is critical because it maps the attack surface, identifies technologies in use, and often reveals misconfigurations or exposed data that can be exploited in later phases.

What is the difference between passive and active information gathering?

Passive information gathering collects data without directly interacting with the target, using sources like search engines, DNS records, and public archives. Active information gathering involves direct interaction such as port scanning, fingerprinting, and crawling the application. Passive techniques are stealthier but provide less detail, while active techniques give more accurate results but may be detected.

What tools are commonly used for web application information gathering?

Common tools include Google Dorking for search engine reconnaissance, Nmap for network scanning, Wappalyzer and WhatWeb for technology fingerprinting, Shodan for internet-connected device discovery, and Burp Suite for mapping application structure. Many testers also use WHOIS lookups, DNS enumeration tools like dig and dnsenum, and web crawlers to build a complete picture of the target.

CyberFolio

Mastering web security testing? Showcase your skills.

Build a free, shareable cybersecurity portfolio that highlights your certifications, projects, and skills.

Build Your Portfolio →

Related WSTG Categories

WSTG-CONF
Configuration and Deployment Management
WSTG-IDNT
Identity Management
WSTG-ATHN
Authentication Testing
WSTG-ATHZ
Authorization Testing
← Back to Home ← All WSTG Categories