Web Application Penetration Testing

We require a practical penetration test of our web-based system, focused mainly on data access, permissions, and exposure risks.
The goal is to confirm whether the system properly protects data from both external unauthenticated users and internal logged-in users with limited access.
1. Testing Objectives
The tester should assess whether:
private data can be accessed without permission
files, reports, exports, or documents are exposed
users can access another user’s data
users can access records by changing IDs in URLs, forms, or API requests
lower-permission users can perform restricted actions
APIs or endpoints expose data incorrectly
role-based permissions and account separation are working correctly
2. Testing Perspectives
External Testing
External testing should be performed without logging in.
The tester should use their own standard methods to assess the public-facing system.
Please test for:
publicly exposed private pages
exposed files, documents, reports, exports, or attachments
login and password reset weaknesses
public API or endpoint exposure
restricted pages accessible without authentication
private data visible in page source, responses, scripts, or network requests
common access-control issues
basic injection or input-handling issues where relevant
The purpose of external testing is to confirm whether an unauthenticated outside user can access anything private or restricted.
Internal Testing
We will provide two test user accounts.
The tester should use these accounts to assess whether logged-in users can access data, pages, files, reports, or actions they should not have access to.
Please test for:
whether Account A can access Account B’s data
whether Account B can access Account A’s data
changing IDs in URLs to view or edit restricted records
modifying API requests to access other users’ records
direct access to restricted pages by URL
access to files, reports, exports, documents, or attachments belonging to another user
attempts to perform restricted actions from a lower-permission account
role/permission bypasses
tenant, client, account, or customer data leakage
hidden UI features or direct routes that expose restricted functionality
The purpose of internal testing is to confirm that each user can only access the data and actions they are authorised to access.
3. Key Areas To Review
Please include testing across the relevant areas of the system, including where applicable:
login
logout
password reset
dashboard
user profile/account pages
customer/client/tenant records
jobs/tasks/orders/bookings
reports
exports
uploaded files or attachments
admin or staff-only areas
API endpoints
direct URLs
browser network requests
page source or client-side data exposure
4. Rules of Engagement
Testing must be safe, controlled, and non-destructive.
The tester must not:
perform denial-of-service testing
perform load or stress testing
send spam
use social engineering or phishing
attack employees, customers, or third-party systems
delete, corrupt, overwrite, or intentionally damage data
attempt persistence, malware, backdoors, or destructive exploitation
access or extract large amounts of real data
If a serious issue is found, the tester should stop further exploitation of that issue and report it immediately with enough evidence to reproduce and fix it.
Testing should stay within the agreed system and accounts provided.
5. Access Provided
We will provide:
system URL
two internal test accounts
explanation of what each account should and should not be able to access
any known role or permission differences between the accounts
any test data required for safe testing
External testing should be performed without using the supplied accounts.
6. Expected Deliverables
Please provide a clear written report.
The report should include:
summary of testing performed
list of vulnerabilities found
severity rating for each issue: Critical, High, Medium, Low
affected area or URL
account used, if relevant
steps to reproduce
screenshots, request examples, or response examples where useful
plain-English explanation of the risk
recommended fix
notes on areas tested where no issue was found
7. Severity Guidance
Use practical severity ratings:
Critical
Unauthorised access to sensitive business/customer data, admin access, or major account separation failure.
High
Access to another user’s records, restricted files, reports, exports, or ability to perform high-impact actions without permission.
Medium
Limited data exposure, permission bypass with limited impact, or weakness that could support a larger issue.
Low
Minor information exposure, missing hardening, or low-impact security improvement.
8. Report Style
We do not need a long formal audit document.
We need a clear, practical report that a developer can act on quickly.
Please keep findings specific and include enough detail to reproduce and fix each issue.
9. Final Outcome Required
At the end of testing, we need a clear answer to:
whether unauthenticated external users can access private data or restricted areas
whether the two provided accounts are properly separated
whether users can access records by changing IDs, URLs, or API requests
whether files, reports, exports, or documents are protected
whether role and permission controls are working correctly