Back to main site

Example report

Example Web Application Security Report

A public sample showing how LetsSecure turns website security testing into clear priorities, evidence and developer-ready fixes.

Findings10
Critical2
AssessmentBlack-box

Executive summary

What matters first

An authenticated black-box security assessment of the demo e-commerce application (ASP.NET Web Forms e-commerce platform) identified 10 confirmed vulnerabilities, including 2 Critical findings. The most severe finding is a stored DOM-based Cross-Site Scripting vulnerability via unsanitized Algolia search product data, which allows arbitrary JavaScript execution in victims' browsers when they interact with search results. A weak password policy (5-character minimum with no complexity requirements) exposes user accounts to credential guessing attacks. Additional medium-severity findings include missing CSRF protection across all state-changing forms, missing rate limiting on authentication endpoints, a client-side reCAPTCHA bypass, session cookie missing the Secure flag, exposed Google Maps API key, version disclosure in response headers, internal subdomain leakage in client-side JavaScript, and reflected input in hidden form fields. The application demonstrates good foundational security posture with properly enforced authentication controls, no SQL injection, no open redirect, no SSRF, and no path traversal vulnerabilities.

This public example shows the type of plain-English report LetsSecure provides after a reviewed website security audit.

Scope and method

How the assessment was run

Assessment conducted per the OWASP Web Security Testing Guide (WSTG) framework. Approach: Reconnaissance and attack surface mapping → Parallel specialized vulnerability testing across 6 categories → Independent validation → Reporting with remediation. Testing categories: SQL Injection (WSTG-INP-09), Cross-Site Scripting (WSTG-INP-01), Insecure Direct Object Reference (WSTG-ATHZ-04), Cross-Site Request Forgery (WSTG-SESS-05), Authentication Testing (WSTG-ATHN-01 through WSTG-ATHN-10), Information Disclosure (WSTG-INFO-01 through WSTG-INFO-09), Session Management (WSTG-SESS-01 through WSTG-SESS-11), and Business Logic (WSTG-BUSL-01).

Client summary

Findings and business impacts

These are the issues that matter in plain language. Technical evidence and reproduction notes are grouped for developers later in this report.

Critical VULN-001

Stored DOM-based Cross-Site Scripting via Unsanitized Algolia Search Data

An attacker can inject malicious JavaScript into Algolia product data fields (ProdName, GroupDesc, CanonicalUrl, PackImage). When any victim searches for or browses affected products, the script executes in their browser context, allowing session hijacking, credential theft, account takeover, and arbitrary actions on behalf of the victim.

Critical VULN-002

Weak Password Policy

The minimum 5-character password requirement with no complexity enforcement allows users to set weak, easily guessable passwords. This significantly reduces the attacker effort required for credential guessing, brute force attacks, and credential stuffing, potentially leading to account takeover of any user account.

Medium VULN-003

Missing CSRF Protection Across State-Changing Endpoints

An attacker can craft cross-origin requests that perform state-changing actions (login, logout, account deletion, password change) on behalf of an authenticated victim without their knowledge or consent, simply by luring them to visit a malicious page while they have an active session.

Medium VULN-004

Missing Rate Limiting on Login and OTP Endpoints

The absence of rate limiting enables attackers to perform unlimited credential guessing (brute force) and OTP brute force attacks against user accounts without throttling or lockout, significantly increasing the risk of account compromise.

Medium VULN-005

Client-Side reCAPTCHA Bypass via Hidden Field Manipulation

An attacker can bypass Google reCAPTCHA verification by manipulating a client-controlled hidden form field (hdnIsCaptchaVerificationSuccess), allowing scripted login attempts and account enumeration without solving CAPTCHA challenges.

Medium VULN-006

ASP.NET_SessionId Cookie Missing Secure Flag

The ASP.NET_SessionId cookie is transmitted over unencrypted HTTP connections, making it susceptible to network-level interception (session hijacking) by attackers on the same network segment.

Medium VULN-007

Unrestricted Google Maps API Key Exposed in Client-Side JavaScript

The exposed Google Maps API key lacks referrer or IP restrictions, allowing unauthorized usage by third parties. This could lead to financial abuse (unbilled API calls), service disruption if the key is revoked, or reputational damage if the key is used in malicious applications.

Medium VULN-008

Reflected Input in Hidden Form Field via PageURL Parameter

The PageURL parameter is reflected into a hidden form field value without encoding. While not directly exploitable as stored XSS due to the hidden field context, it increases the attack surface and could potentially be leveraged in DOM-based attacks or open-redirect scenarios.

Medium VULN-009

ASP.NET Version and UrlRewriter.NET Version Disclosure

Exposed version information enables attackers to identify known vulnerabilities (CVEs) for ASP.NET 4.0.30319 and UrlRewriter.NET 1.7.0, facilitating targeted exploitation.

Medium VULN-010

Internal Subdomain and API Endpoint Exposure in JavaScript Source

Exposure of internal subdomains (admin, api, web, cfjump) and internal API endpoint patterns expands the attack surface by revealing potentially less-secure internal services and undocumented API endpoints.

Remediation roadmap

Recommended order of work

Immediate

  • Remediate stored DOM XSS (VULN-001): Sanitize all Algolia product data with DOMPurify before DOM injection. Implement Content-Security-Policy header.
  • Increase password strength requirements (VULN-002): Enforce minimum 8-char length with complexity requirements.
  • Implement CSRF protection (VULN-003): Add Anti-Forgery Tokens to all state-changing forms using ASP.NET's built-in anti-CSRF features.
  • Fix server-side CAPTCHA validation (VULN-005): Remove client-side hdnIsCaptchaVerificationSuccess field; validate reCAPTCHA server-side with Google's API.

Short term

  • Implement rate limiting on login and OTP endpoints (VULN-004): 5 attempts per 15 min/IP, account lockout after 10 failures.
  • Add Secure flag to ASP.NET_SessionId cookie (VULN-006): Set requireSSL="true" in web.config.
  • Restrict Google Maps API key (VULN-007): Add HTTP referrer restrictions and API method restrictions.
  • Apply HtmlEncode to PageURL parameter (VULN-008): Encode user input before reflecting in HTML.
  • Remove version disclosure headers (VULN-009): Strip X-AspNet-Version and X-Powered-By headers.
  • Secure internal subdomains (VULN-010): Ensure all subdomains have consistent security configuration.

Medium term

  • Implement a Web Application Firewall (WAF) ruleset specifically for the ASP.NET stack
  • Conduct a penetration test targeting internal subdomains (admin, api, web)
  • Implement CSP headers with strict script-src restrictions as defense-in-depth against XSS
  • Review and harden cookie configuration: all auth cookies should have Secure + HttpOnly + SameSite flags
  • Implement comprehensive logging and monitoring for authentication failures and suspicious patterns

Secure areas

Tested without confirmed vulnerability

Developer detail

Evidence, reproduction notes and remediation

Critical VULN-001

Stored DOM-based Cross-Site Scripting via Unsanitized Algolia Search Data

Endpoint/search?search=* and autocomplete endpoint
MethodGET
CWECWE-79

Remediation: Sanitize all Algolia product data fields using DOMPurify before DOM injection. Replace .append(htmlString) with .text() or use createTextNode() for user-controlled content. Implement a Content-Security-Policy header with script-src restrictions as defense-in-depth.

Evidence and reproduction notes
  1. Search for any product on the site
  2. Observe that product names and descriptions are dynamically rendered in search results
  3. The response is rendered client-side via jQuery .append() from Algolia data
  4. If a product's name contained <img src=x onerror=alert(document.cookie)>, it would execute when users view search results for that product
Critical VULN-002

Weak Password Policy

Endpoint/login.aspx and /changepassword.aspx
MethodPOST
CWECWE-521

Remediation: Increase minimum password length to at least 8 characters. Enforce complexity requirements: at least one uppercase letter, one lowercase letter, one digit, and one special character. Implement password strength meter on registration and password change forms. Consider using a password library (e.g., zxcvbn) for strength estimation.

Evidence and reproduction notes
  1. Attempt to register a new account or change password to 'abcde'
  2. The password is accepted despite having no uppercase, digits, or special characters
  3. Any 5+ character string with at least one non-whitespace character is accepted
Medium VULN-003

Missing CSRF Protection Across State-Changing Endpoints

Endpoint/login.aspx, /signout.aspx, /account-deletion.aspx, /changepassword.aspx, /profileupdate.aspx
MethodPOST / GET
CWECWE-352

Remediation: Implement ASP.NET Anti-Forgery Tokens (__RequestVerificationToken) on all state-changing forms using @Html.AntiForgeryToken() and [ValidateAntiForgeryToken] attribute. Convert GET-based state changes (signout, account deletion) to POST-only with token validation. Set SameSite cookie attribute to Strict or Lax.

Evidence and reproduction notes
  1. Create an HTML page with a form that POSTs to https://shop.example/signout.aspx
  2. Host the page and lure an authenticated victim to visit it
  3. The victim's session is silently logged out
  4. For login CSRF: a form auto-submitting to /login.aspx with known credentials binds the victim's session to the attacker's account
Medium VULN-004

Missing Rate Limiting on Login and OTP Endpoints

Endpoint/login.aspx, /login.aspx/CheckEmail, /login.aspx/ValidateUser
MethodPOST
CWECWE-307

Remediation: Implement rate limiting on login endpoints: max 5 failed attempts per IP per 15 minutes before temporary block. Implement account lockout after 10 failed attempts with progressive delay. Rate-limit OTP requests to max 3 per email per 10 minutes. Add CAPTCHA challenge after 3 failed login attempts. Log and monitor all authentication failures.

Evidence and reproduction notes
  1. Send 25+ sequential POST requests to /login.aspx with an invalid password
  2. Observe that all 25+ requests are processed without throttling
  3. Send 20+ OTP requests to the same email
  4. Observe all requests complete without rate limiting being enforced
Medium VULN-005

Client-Side reCAPTCHA Bypass via Hidden Field Manipulation

Endpoint/login.aspx
MethodPOST
CWECWE-807

Remediation: Remove the client-side hdnIsCaptchaVerificationSuccess field. On each form submission, send the reCAPTCHA response token to the server and validate it server-side using Google's reCAPTCHA verification API (https://www.google.com/recaptcha/api/siteverify). Never trust client-side verification flags.

Evidence and reproduction notes
  1. Intercept a login POST request
  2. Add/modify the parameter hdnIsCaptchaVerificationSuccess=true to the request body
  3. Send the request without including a valid reCAPTCHA token
  4. Observe that the server accepts the login attempt without verifying the CAPTCHA
Medium VULN-006

ASP.NET_SessionId Cookie Missing Secure Flag

Endpoint/login.aspx (response Set-Cookie header)
MethodN/A
CWECWE-614

Remediation: Add the Secure flag to the ASP.NET_SessionId cookie. In ASP.NET, set <httpCookies requireSSL="true" /> in web.config. Additionally, ensure the _VSSiteCookie also has Secure and HttpOnly flags.

Evidence and reproduction notes
  1. Observe the Set-Cookie response header from /login.aspx
  2. The ASP.NET_SessionId cookie lacks the Secure flag
  3. This enables transmission over unencrypted HTTP connections
Medium VULN-007

Unrestricted Google Maps API Key Exposed in Client-Side JavaScript

Endpoint/pages/contactus.aspx (client-side JavaScript)
MethodGET
CWECWE-200

Remediation: Restrict the API key to specific HTTP referrer URLs (only shop.example). Restrict API key usage to only required APIs (Maps JavaScript API). Consider using API key rotation. Implement separate keys for development/staging/production environments.

Evidence and reproduction notes
  1. Extract the Google Maps API key from the contact page JavaScript source
  2. Use the key in a Maps API request from an arbitrary domain
  3. Observe that the API responds successfully without referrer validation
Medium VULN-008

Reflected Input in Hidden Form Field via PageURL Parameter

Endpoint/login.aspx
MethodGET
CWECWE-79

Remediation: Apply HtmlEncode to the PageURL parameter value before rendering it into the HTML response. Validate and sanitize the PageURL parameter to accept only relative paths or known-safe URLs. Consider removing the reflection entirely if the parameter is not needed.

Evidence and reproduction notes
  1. Visit /login.aspx?PageURL="test123
  2. Observe that the PageURL value is reflected unencoded in the response HTML
  3. The injection breaks the value attribute context of the hidden input field
Medium VULN-009

ASP.NET Version and UrlRewriter.NET Version Disclosure

EndpointMultiple endpoints (response headers)
MethodGET
CWECWE-200

Remediation: Remove X-AspNet-Version header by setting <httpRuntime enableVersionHeader="false" /> in web.config. Remove or obscure X-Powered-By header via IIS URL Rewrite rules or custom headers module. Use a response header removal module to strip unnecessary version information.

Evidence and reproduction notes
  1. Send GET request to any page on the application
  2. Observe the X-AspNet-Version: 4.0.30319 header in response
  3. Observe X-Powered-By: UrlRewriter.NET 1.7.0 header
  4. These disclose the exact framework versions to potential attackers
Medium VULN-010

Internal Subdomain and API Endpoint Exposure in JavaScript Source

EndpointClient-side JavaScript files
MethodGET
CWECWE-200

Remediation: Review all internal subdomains for consistent security configurations and access controls. Remove internal subdomain references from client-side code where possible. Ensure api.shop.example and admin.shop.example are not exposed to the public internet without authentication. Implement consistent security headers across all subdomains.

Evidence and reproduction notes
  1. View source of JavaScript files loaded on the site
  2. Search for internal hostnames and domain patterns
  3. Discover references to admin, api, web, and cfjump subdomains
  4. These subdomains expand the attacker's target surface

Retest guidance

What to verify after fixes

After implementing the immediate and short-term recommendations, a retest should focus on: (1) Confirming the Algolia stored XSS is remediated by verifying product data is properly sanitized before DOM injection; (2) Verifying CSRF tokens are present and validated on all state-changing forms; (3) Confirming rate limiting is enforced on login and OTP endpoints; (4) Verifying server-side reCAPTCHA validation cannot be bypassed; (5) Confirming version disclosure headers are removed; (6) Testing internal subdomains for consistent security posture.