Case Study: Municipal Government Digital Infrastructure

Independent Application Security Assessment

Engagement Type: Authorized Bug Bounty (Managed Program)
Assessment Period: February 2026
Vulnerability Class: Information Disclosure (Configuration)

---

Executive Overview

A security assessment of a municipal government digital infrastructure revealed multiple information disclosure vulnerabilities across authentication and API layers. While the organization's core security posture was mature — with proper cryptographic controls, mutual TLS enforcement, and well-configured security headers — several issues were identified that reduce defense-in-depth and could aid an attacker in reconnaissance or further exploitation.

This case study examines how information disclosure vulnerabilities — often dismissed as low severity — form the foundation of higher-impact attack chains.

---

Organizational context

Sector: Government / Public Administration.

Authentication Stack: SAML 2.0, Azure AD, and OIDC.

Technology Stack: ASP.NET, Liferay CMS, WordPress, and Apache.

Regulatory Context: GDPR and the National Data Protection Act.

Engagement Channel: Managed Bug Bounty Program.

---

Validated Vulnerabilities

Finding 1: Internal IP Address Disclosure

Severity: Informational
Category: Server Security Misconfiguration > Fingerprinting/Banner Disclosure
CWE: CWE-200 — Exposure of Sensitive Information

Technical Detail

Authentication responses transmitted during the user login flow included the internal IP address of the authentication server embedded in XML attributes.

Impact Analysis

In isolation, this finding has limited direct exploitability. However, it becomes a critical component of a server-side request forgery (SSRF) attack chain — establishing internal network segments that host authentication services.

Lesson

Information disclosure findings must be framed in terms of their combinatorial potential, not their standalone impact.

---

Finding 2: API Authorization Token Disclosure in Error Responses

Severity: Informational
Category: Server Security Misconfiguration > Fingerprinting/Banner Disclosure
CWE: CWE-209 — Error Message Containing Sensitive Information

Technical Detail

When a registration endpoint receives malformed input, error responses include the complete outbound request details — including authorization headers used for backend API communication.

Compensating Control

Direct access to the backend API was blocked by mutual TLS, preventing immediate exploitation. However, this is a defense-in-depth failure — if mTLS is misconfigured or bypassed (e.g., via SSRF), the token provides ready-made credentials for internal API access.

Lesson

When a compensating control blocks exploitation, document it explicitly to demonstrate thorough testing and show reviewers exactly why the risk is contained — while preserving the finding's validity.

---

Finding 3: Internal Infrastructure Disclosure via Verbose Error Messages

Severity: Informational
Category: Server Security Misconfiguration > Fingerprinting/Banner Disclosure
CWE: CWE-209 — Error Message Containing Sensitive Information

Technical Detail

Multiple error conditions returned detailed technical information revealing internal system architecture — internal hostnames, backend API endpoints, internal domains, and implementation details.

Collective Impact

Individually, each error message is low value. Collectively, they provide an attacker with a reconnaissance package — everything needed to target internal infrastructure if a request forgery primitive is found.

---

Finding 4: Example Metadata Warning in Production Configuration

Severity: Informational
Category: Server Security Misconfiguration > Fingerprinting/Banner Disclosure
CWE: CWE-1188 — Insecure Default Initialization

Technical Detail

Publicly accessible service provider metadata contained comments from default example configuration indicating template deployment without full review.

---

Security Controls Assessment

The following controls were properly implemented:

Authentication and Cryptography

• SAML responses signed with strong cryptography
• Signature validation enforced on all assertions
• Audience restriction properly configured
• Replay prevention via correlation validation
• Backend API protected by mutual TLS

Infrastructure

• No subdomain takeover vulnerabilities identified
• Internal portals properly restricted
• Known CVEs not exploitable in current configuration
• ViewState MAC validation enabled

Security Headers

• HSTS properly configured
• X-Content-Type-Options: nosniff
• X-XSS-Protection implemented
• Content-Security-Policy implemented

Access Controls

• Debug endpoints disabled
• Configuration files not exposed
• Custom error pages enabled

---

The Attack Chain Concept

The most important insight from this engagement is the relationship between individually low-severity findings and their collective potential.

What Was Found (In Isolation)

• Internal IP address disclosure → Informational
• API token disclosure in errors → Informational
• Internal hostname and endpoint disclosure → Informational
• Default metadata comment → Informational

What They Enable Together

1. Identify internal API endpoint structure
2. Obtain authorization token for that API
3. Confirm internal network segment hosting auth services
4. [Unknown] Find SSRF vulnerability on any property
5. Route authenticated requests to internal API through SSRF vector
6. Potential: Internal data access, auth bypass — Critical severity

The Gap

This chain was not completed during the assessment. No SSRF vulnerability was identified. Without the SSRF primitive, the findings remain informational.

This is the core lesson: information disclosure findings are latent vulnerabilities. Their severity is determined by what else an attacker can find alongside them.

---

Triage Outcome

All findings were accepted as valid and classified as Informational under Server Security Misconfiguration > Fingerprinting/Banner Disclosure.

The findings were not wrong — they were incomplete. The difference between severity levels was not the existence of the vulnerabilities but the demonstrated impact.

The gap is impact demonstration, not finding identification.

---

Recommendations

Immediate

1. Remove internal IP addresses from authentication responses
2. Sanitize error responses — remove authorization headers and internal endpoint details from public errors

Short-Term

1. Implement generic API error responses
2. Review and clean production configuration metadata

Strategic

1. Conduct SSRF audit given exposed internal infrastructure details
2. Implement automated error message scanning in CI/CD

---

Key Takeaways for Security Teams

1. Information Disclosure is a Force Multiplier

A single piece of leaked information is rarely exploitable. A collection — internal IPs, hostnames, API endpoints, authorization tokens — becomes a reconnaissance package that dramatically reduces attack effort.

2. Defense-in-Depth Gaps Are Still Gaps

Compensating controls do not eliminate risk — they defer it. If a control is ever misconfigured, removed, or bypassed, exposure immediately becomes critical.

3. Error Messages Are a Free Recon Tool

Internal hostnames, endpoint paths, field names, data types, and framework versions reduce the time required to map an attack surface. Generic error messages are one of the cheapest security improvements available.

4. Chaining Matters More Than Individual Findings

An Informational finding combined with another Informational finding can constitute a Critical attack chain. Vulnerability management programs should account for this.

---

Organization details shared with explicit program authorization via public bug bounty platform.