Introduction
Web application security is no longer optional—it is a business necessity. With cyberattacks becoming increasingly sophisticated, organizations must proactively identify and fix vulnerabilities before they can be exploited.
This post presents a sample penetration testing report I prepared for a hypothetical web application (vsite.com). The report demonstrates the depth of analysis, types of vulnerabilities uncovered, and the actionable remediation strategies I provide to clients.
Whether you are a developer, security enthusiast, or business owner, this post will give you a clear understanding of what a professional web application security assessment looks like.
Table of Contents
- Executive Summary
- Scope of Assessment
- Detailed Security Findings
- Impact Analysis
- Remediation Recommendations
- Conclusion
- About the Author
Executive Summary
This report presents the results of a comprehensive assessment of the web application conducted to identify security vulnerabilities, functionality issues, and user experience problems. The objective of this assessment is to help improve the application's security, stability, performance, and overall user experience.
Scope of Assessment
The assessment covers:
- Web application penetration testing
- Functional testing review
- Authentication and authorization checks
- Input validation testing
- Session management analysis
- File upload security
- Business logic testing
- Client-side security checks
Website Tested: vsite.com (hypothetical)
Detailed Security Findings
1. Information Disclosure – Cloudflare Analytics Token
The application is leaking Cloudflare analytics configuration details, including the analytics token and version information, through the data-cf-beacon attribute in the script tag.
Remediation: Remove the data-cf-beacon script tag from the HTML to stop exposing the analytics token.
2. Missing Rate Limiting
The application does not implement rate limiting on its endpoints, leaving it vulnerable to brute-force attacks and automated submissions.
Remediation: Implement rate limiting on all endpoints (e.g., 5–10 requests per minute per IP) using middleware, Nginx, or Cloudflare to prevent brute-force and automated attacks.
3. Cross-Site Scripting (XSS) Vulnerability
The contact form at vsite.com/contact is vulnerable to Cross-Site Scripting (XSS) attacks, as evidenced by the successful injection of the payload "><img src=x onerror=alert(1)> into several fields.
Remediation: Apply output encoding (HTML entity encoding) for all user-supplied data rendered in the browser and implement strict input validation/sanitization to reject or neutralize dangerous characters like <, >, ", ', and &. Additionally, deploy a Content Security Policy (CSP) to prevent execution of inline scripts.
4. Missing Rate Limiting on File Uploads
The application does not implement rate limiting for file uploads, allowing attackers to upload multiple files in rapid succession without restriction.
Remediation: Apply rate limiting specifically to file upload endpoints (e.g., max 5 uploads per minute per IP/user) and enforce file size limits.
5. Insecure Session Cookie Configuration
The session cookie ci_session at https://vsite.com is configured without the Secure flag, meaning it can be transmitted over unencrypted HTTP connections, making it vulnerable to network sniffing and session hijacking attacks.
Remediation: Set the Secure flag on the ci_session cookie and enforce HTTPS site-wide using HSTS to prevent transmission over unencrypted connections. Also set HttpOnly and SameSite=Strict attributes for additional protection.
6. Missing CSRF Protection on Contact Form
The contact form should include a CSRF token to protect against Cross-Site Request Forgery (CSRF) attacks.
Remediation: Generate a unique, unpredictable CSRF token per user session and embed it as a hidden field in the contact form; validate this token on the server side for all POST requests. Also set SameSite=Strict or Lax attribute on session cookies for defense in depth.
7. Server-Side Template Injection (SSTI)
The application allows users to register with the name {{7*7}} on https://vsite.com/favouriteuser.
Remediation: Sanitize and escape all user inputs before rendering in templates, and disable dynamic expression evaluation in the template engine to prevent Server-Side Template Injection.
8. Insecure File Upload Restrictions
The profile photo upload functionality (https://vsite.com/usereditprofile) does not properly restrict file uploads to allowed image formats.
Remediation: Restrict file uploads to allowed image MIME types (e.g., image/jpeg, image/png, image/gif), validate file extensions and magic bytes, and store uploaded files outside the web root with randomly generated names.
9. Weak Client-Side Validation
The login button remains clickable even when the password field is empty.
Remediation: Add client-side validation to disable the login button or display an error until both username and password fields are filled, and enforce server-side validation to reject empty or incomplete submissions.
10. Weak Password Policy
The registration page (https://vsite.com/register) enforces a weak password policy.
Remediation: Enforce a strong password policy requiring minimum 8 characters, including uppercase, lowercase, number, and special characters, and reject common passwords using a dictionary check or HaveIBeenPwned API.
11. Missing CSRF Protection on Logout
The endpoints https://vsite.com/logout do not use CSRF protection, allowing an attacker to trick a logged-in user into performing these actions.
Remediation: Implement CSRF tokens on the logout endpoint and require POST requests for logout actions instead of GET; also set SameSite=Strict attribute on session cookies.
12. JavaScript Injection in Contact Form Fields
The Subject and Message fields on https://vsite.com/contactus accept JavaScript code as input.
Remediation: Apply strict input validation to reject JavaScript/HTML payloads, use output encoding for all rendered user input, and implement a Content Security Policy to prevent script execution.
13. Weak Password Policy on Change Password Form
The change password form at https://vsite.com/changepassword allows users to set very weak passwords such as 123.
Remediation: Enforce the same strong password policy on the change password form (minimum 8 characters with uppercase, lowercase, number, and special character), and reject common weak passwords using a dictionary or HaveIBeenPwned API.
14. Session Management – Registration Page Accessible After Login
When already logged in at https://vsite.com/docdashboard, the application still allows access to the registration page at https://vsite.com/register.
Remediation: Implement session-aware access controls to redirect authenticated users away from registration and login pages (e.g., to their dashboard) by checking session status on the server side before rendering these pages.
15. Cached Pages After Logout
After logging out from the user dashboard (https://vsite.com/dashboard), pressing the browser's Back button displays the dashboard again.
Remediation: Set cache-control headers (Cache-Control: no-cache, no-store, must-revalidate, Pragma: no-cache, Expires: 0) on authenticated pages and invalidate the session server-side upon logout to prevent cached pages from being displayed after logout.
16. Login Page Accessible After Login
When already logged in, the application still allows access to the login page (https://vsite.com/login).
Remediation: Redirect authenticated users away from the login page to their dashboard by checking session status server-side before rendering the login page.
17. Duplicate Registration Page Access Issue
When already logged in, the application still allows access to the registration page (https://vsite.com/register).
Remediation: Redirect authenticated users away from the registration page to their dashboard by checking session status server-side before rendering the registration page.
18. Sensitive Paths in Robots.txt
The robots.txt file (https://vsite.com/robots.txt) disallows crawling of the login page (https://vsite.com/login/).
Remediation: Remove the login page disallow rule from robots.txt or update it to only block truly sensitive/internal paths, as robots.txt should not be relied upon for security and login pages should be protected by authentication instead.
19. Anonymous FTP Access
The FTP server on vsite.com allows anonymous login, enabling users to connect without valid authentication credentials.
Remediation: Disable anonymous FTP access immediately and require strong authentication credentials; additionally, migrate to SFTP or FTPS for encrypted file transfers.
20. Missing CSRF Protection on Document Upload
There is a complete absence of CSRF protection on the document upload form located in https://vsite.com/upload-document.
Remediation: Implement CSRF tokens on the document upload form and validate them server-side for all POST requests, and set SameSite=Strict attribute on session cookies for additional protection.
21. Hardcoded Credentials Exposed in HTML
Login credentials (username and password) are being exposed in plain text within the HTML of the page at https://vsite.com.
Remediation: Immediately remove hardcoded credentials from the HTML source and never embed sensitive data in client-side code; store all secrets in environment variables or secure vaults and enforce their use server-side only.
Impact Analysis
The identified issues may expose the application to:
- Security risks and data compromise
- Unauthorized access and session hijacking
- Functional failures and broken business logic
- Degraded user experience
- Reputational damage and legal liabilities
Addressing these findings will strengthen the application's security, reliability, performance, and overall usability.
Remediation Strategy
Implement the recommended security controls, input validation, access restrictions, and code fixes to address the identified vulnerabilities and functional issues. After applying the fixes, perform a comprehensive retest to verify that all issues have been resolved and no new vulnerabilities have been introduced.
Conclusion
This sample report illustrates the importance of regular web application security assessments. Vulnerabilities ranging from information disclosure to injection attacks and broken access controls can have severe consequences if left unaddressed.
A professional penetration test not only identifies these weaknesses but also provides clear, actionable steps to fix them. Security is not a one-time activity—it is an ongoing process that requires continuous attention and improvement.
If you are looking for a thorough security assessment for your web application, or need assistance with vulnerability remediation, secure code review, or post-remediation retesting, feel free to reach out.
About the Author
Abhinav Singwal
Web Application Penetration Tester
I specialize in identifying security vulnerabilities, functionality issues, and user experience problems in web applications. My goal is to help organizations build secure, reliable, and user-friendly applications.
- Email: abhinavsingwal@gmail.com
- LinkTree: https://linktr.ee/abhinavsingwal
Top comments (0)