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

Project ID: 40511288