ExamFinch.com My Study

Study guide

11.5 Information Disclosure: Error Messages & Mark-up Leakage

Practice this exam

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

11.5 Information Disclosure: Error Messages & Mark-up Leakage

Key Takeaways Explain This Topic AI

Verbose error messages disclose software versions, file-system paths, SQL fragments, stack traces and internal hostnames that map the application's internals.

The HTTP status code and the error body must both be reviewed: a 500 with a stack trace is far more useful than the code alone.

HTML source routinely leaks hidden form fields, developer comments, connection strings, credentials, API keys and links to authenticated-only URLs.

Client-side JavaScript and its source maps expose endpoints, feature flags and logic not visible in the rendered page.

Remediation is generic error pages, server-side logging of detail, and removing sensitive content from client-delivered mark-up and scripts.

Last updated: September 2026

11.5 Information Disclosure: Error Messages & Mark-up Leakage

Two syllabus items combine into a single discipline: reading what the application tells you that it did not mean to. H8 (Information Disclosure in Error Messages) covers how error messages indicate or disclose useful information. H3 (Information Gathering from Web Mark-up) covers the intelligence in web page source — hidden form fields, database connection strings, credentials, developer comments, other included files, and authenticated-only URLs.

Neither is a dramatic exploit on its own. Both are force multipliers: they turn a black-box target into a partially white-box one, telling you the software, the versions, the file paths, the hidden parameters and often the credentials that make every subsequent attack faster and more reliable.

1. Information Disclosure Through Error Messages (H8)

When an application encounters an unexpected condition, a poorly configured one tells the user what went wrong in technical detail . That detail is written for a developer debugging locally, not for an anonymous internet user, and it leaks accordingly.

What Errors Disclose

  • Error content Intelligence it hands the attacker
  • Stack trace Framework and exact version, class and method names, file-system paths, line numbers

SQL error The DBMS and version, table/column names, and often the injected query itself — the engine of error-based SQLi (12.2)

  • Path in an error The web root and directory layout, enabling path traversal and LFI (11.1)
  • "File not found: /var/www/app/inc/db.php" Absolute paths, include structure, technology ( .php )
  • Internal hostname / IP in an error Back-end topology (database server names, internal addresses)
  • Differing error for valid vs invalid username Username enumeration (H4)

Version banners in default error pages The Apache/IIS/nginx and app-server versions to match against advisories

Status Codes and Bodies Together

Review both the HTTP status code (section 10.1) and the response body. A bare 500 Internal Server Error is uninformative; a 500 whose body contains a full framework stack trace is a map of the application. Equally, differences in behaviour matter more than any single response: an application that returns 404 for a non-existent file but 403 for one that exists-but-is-forbidden has just disclosed which files exist. Deliberately provoke errors to harvest this:

  • submit unexpected types (a string where a number is expected, an array where a scalar is expected);
  • send malformed input (broken JSON/XML, an oversized value, a null byte);
  • request non-existent and forbidden resources;

interrupt multi-step flows out of order.

The Debug-Mode Trap

The single richest source is an application left in debug/development mode in production — Django's debug page, ASP.NET's "yellow screen of death" with customErrors="Off" , Rails' exception page, PHP with display_errors=On . These render the full stack, local variables, configuration and sometimes environment variables (including secrets) directly to the browser. Finding one is a high-severity finding on its own.

2. Information Gathering from Web Mark-up (H3)

The rendered page is only part of what the server sends. The source — HTML, comments, inline scripts, linked files — carries far more, and it costs nothing to read ( Ctrl+U , curl , or Burp's response view).

Hidden Form Fields

<input type="hidden"> values are invisible in the browser but fully present in the source and fully editable by the client. They routinely carry prices, user IDs, roles, quantities, discount flags and state that the developer assumed the user could not change — the foundation of parameter tampering (11.1). A hidden <input name="price" value="9.99"> or <input name="isAdmin" value="false"> is a classic finding.

Developer Comments

HTML and JavaScript comments are delivered to the client verbatim. They disclose:

  • work-in-progress notes ("TODO: remove test admin account before go-live");
  • disabled or commented-out functionality and its URLs;
  • credentials and connection strings pasted "temporarily";
  • internal ticket numbers, developer names and email addresses;

explanations of how a control works, which explains how to defeat it.

Connection Strings, Credentials and Keys

Secrets end up in client-delivered content more often than anyone expects: a database connection string in an HTML comment or an inline script, a third-party API key hardcoded in JavaScript, AWS keys in a bundled config, Basic-auth credentials embedded in a URL. Search the source and every linked script for password , passwd , secret , apikey , api_key , connectionString , AKIA (AWS), and private-key headers.

Other Included Files and Authenticated-Only URLs

Linked resources — <script src> , <link href> , source-map ( //# sourceMappingURL ) references, and paths in JavaScript reveal the file structure and additional endpoints.

Authenticated-only URLs — the mark-up frequently references admin panels, API endpoints or privileged functions that are hidden from the UI by CSS or conditional rendering but present in the source. These feed forced browsing (10.3) and access-control testing: a link to /admin/users present in the page of a non-admin user is a lead to a broken-access-control finding.

Client-Side JavaScript

Modern single-page applications ship much of the application's structure in JavaScript. Reading the bundles (beautified, and via source maps where present) reveals every API endpoint the front-end knows about , feature flags, role names, and validation logic — a comprehensive endpoint list for testing, often including routes never linked in the visible UI. Tools like LinkFinder and Burp extract URLs and parameters from JS automatically.

3. A Systematic Review For every response the application returns:

  • 1. Read the status code AND the body
  • 2. View source: HTML comments, hidden fields, inline scripts
  • 3. Fetch and beautify every linked JS/CSS file; follow source maps
  • 4. Grep source + scripts for: password secret apikey connectionString
  • AKIA BEGIN PRIVATE KEY /admin /api TODO
  • 5. Provoke errors deliberately; capture verbose output and paths
  • 6. Compare responses (valid vs invalid, exists vs forbidden)
  • 7. Feed discovered endpoints/params back into content discovery + access tests
  • 4. Remediation

The fixes are well understood and worth stating precisely in a report:

Generic error pages for all unhandled exceptions; log the technical detail server-side where only administrators see it. Disable debug mode in production ( customErrors="On" , display_errors=Off , DEBUG=False ).

Consistent responses where disclosure would aid enumeration — identical messages and timing for valid and invalid usernames, identical handling for existing-but-forbidden and non-existent resources.

Do not put secrets in client-delivered content — no credentials, connection strings or API keys in HTML, comments or JavaScript; keep secrets server-side and inject third-party keys through a back-end proxy where possible.

Strip comments and source maps from production builds, and remove hidden fields that carry security-relevant state — move that state server-side (session) and never trust a client-supplied price or role.

Suppress version banners in server and framework headers and default pages.

The through-line is the same as the rest of the web chapters: the client sees everything the server sends, so nothing sensitive should be sent, and nothing the client can alter should be trusted.