Web Application Security Assessment
An authorised penetration test was conducted on the Acme Webshop web application between 10–14 March 2026. The assessment identified 7 vulnerabilities across three severity levels. Two critical issues were identified that could directly result in financial loss or unauthorised account access.
All testing was performed with explicit written authorisation. No production data was modified and no real transactions were completed.
| # | Title | Severity | Status |
|---|---|---|---|
| F-01 | Price manipulation via client-side parameter | Critical | Open |
| F-02 | Stored XSS in order notes field | Critical | Open |
| F-03 | IDOR on order PDF endpoint | High | Open |
| F-04 | No rate limiting on login endpoint | High | Fixed |
| F-05 | Missing server-side date validation | Medium | Open |
| F-06 | Verbose error messages expose stack traces | Medium | Fixed |
| F-07 | Missing security headers (CSP, HSTS) | Low | Open |
The add-to-cart request includes a price parameter that is accepted and processed server-side without validation. An attacker can set an arbitrary price — including zero or negative values — for any product.
price parameter to 0.01Request with manipulated price parameter. Server responded with 200 OK and confirmed price of €0.01.
Any authenticated or guest user can purchase products at an arbitrary price, resulting in direct financial loss for the organisation.
Remove the price parameter from all client-facing requests. Prices must be determined exclusively server-side based on the product ID. Never trust client-supplied pricing data.
The order notes field during checkout accepts and stores unsanitised HTML and JavaScript. When an administrator views the order in the backend, the stored script executes in their browser session.
Full administrator session takeover. An attacker gains access to all customer data, order history, and backend functionality without knowing any credentials.
htmlspecialchars() in PHP)The order confirmation PDF is accessible via a predictable sequential URL. Any authenticated user can access PDFs belonging to other customers by incrementing the order ID.
/files/order/10482.pdf10481, 10480, etc.Personal data of all customers (name, address, email, order contents) is accessible to any authenticated user. This constitutes a GDPR data breach.
Verify server-side that the requesting user is the owner of the requested order before serving the PDF. Alternatively, use cryptographically random, non-guessable tokens in the URL instead of sequential IDs.
The login endpoint /account/login has no rate limiting or account lockout mechanism. An attacker can attempt unlimited password guesses programmatically.
/account/login with a known usernameImplement rate limiting (e.g. max 5 attempts per 15 minutes per IP), account lockout after repeated failures, and CAPTCHA for suspicious activity.
Booking dates are validated client-side only. By manipulating the date parameter in the API request, it is possible to book for dates in the past or far in the future beyond the allowed booking window.
Validate all date parameters server-side against the actual availability calendar. Reject requests with dates outside the permitted range with an appropriate error response.
Certain invalid requests trigger unhandled exceptions that return full PHP stack traces including file paths, database table names, and internal function calls. This information aids an attacker in mapping the application internals.
Disable debug mode in production. Return generic error messages to the client and log detailed errors server-side only.
The application is missing several recommended HTTP security headers: Content-Security-Policy, X-Content-Type-Options, and Referrer-Policy. While not directly exploitable, their absence increases the attack surface.
Add the following headers to all responses via the web server configuration:
The assessment revealed significant security weaknesses in the application's input validation, access control, and business logic. The two critical findings (F-01, F-02) should be treated as immediate priorities as they pose a direct risk of financial loss and data compromise.
The following remediation priority order is recommended:
A follow-up retest is recommended after remediation of the critical and high findings to verify that fixes are effective and have not introduced new issues.
Testing was performed manually using browser DevTools, custom scripts, and standard security tooling. The assessment followed the OWASP Web Security Testing Guide (WSTG v4.2) and covered the following areas:
Out of scope: Infrastructure, network layer, third-party integrations, social engineering.