Penetration testing

• 01

  You are about to launch, or just did.

• 02

  A client, investor or regulator asks for a security assessment.

• 03

  You handle payments, health data or anything worth stealing.

• 04

  It has been a year since anyone looked.

1. D/01

   Scoped engagement

   Before any test, we agree in writing what may be tested, how and when. The rules of engagement name the targets, what is off limits, the test windows and who to call, so every test is authorised and nothing surprises your team.

   Included

   • The targets in scope, and what is out
   • Test windows and limits on load
   • Test accounts for each role
   • Emergency contacts and a way to stop the test at once

   Rules of engagement · Clinic booking platform

   Signed by both parties · 3 September

   In scope

   • app.staging.example.com and api.staging.example.com
   • The iOS and Android apps, build 2.4

   Out of scope

   • The payment provider and the SMS gateway.
   • Denial of service, social engineering, physical access.

   Windows

   • Staging at any time; production Sat–Wed, 10:00–16:00, read-only.

   Contacts

   • Your on-call engineer by phone; either side can stop the test.

2. D/02

   Hands-on testing

   Tools map the surface, then people do the testing: logging in as one user and asking for another’s data, replaying requests, changing a price halfway through checkout. Most serious flaws live in business logic, where scanners cannot see.

   Included

   • Authentication, sessions and password reset
   • Access control between users and roles
   • Injection, file uploads and server-side requests
   • Business logic: payments, discounts and workflows

   $ GET /api/bookings/8812 (token: patient A)

   200 OK · booking 8812 · owner patient A

   $ GET /api/bookings/8813 (token: patient A)

   × 200 OK · booking 8813 · owner patient B

   leaks: phone, date of birth, visit notes

   ! ownership is not checked on booking reads

   ✓ logged as F-01 · evidence req-0412, req-0413

3. D/03

   Rated findings

   Each finding is rated with CVSS and backed by evidence: the request, the response, the impact and the steps to reproduce it. Your developers can confirm every issue themselves before they start fixing it.

   Included

   • A CVSS 3.1 score and vector for each finding
   • Requests, responses and screenshots as evidence
   • Steps to reproduce, in order
   • The real impact on your business and users

   ID	Severity	Finding	CVSS
   F-01	High	Any patient can read other patients’ bookings	7.5
   F-02	High	Password reset links never expire	7.4
   F-03	Medium	No rate limit on login codes	6.5
   F-04	Medium	Stored XSS in clinic notes	5.4
   F-05	Low	Error pages show stack traces	3.7
   F-06	Low	Missing security headers	3.1

4. D/04

   Fix guidance

   Each finding comes with a fix written for your stack and your code. Where it helps, we include the changed query or the middleware to add, and a test that proves the fix holds.

   Included

   • The root cause, in one or two sentences
   • A concrete fix for your framework and language
   • A test that fails before the fix and passes after
   • Other places in the code with the same pattern

   F-01 · Check who owns a booking

   High · CVSS 7.5 · AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

   Cause

   • GetBooking loads a booking by id and never compares it to the caller.

   Fix

   • Filter by owner in the query itself:
   • WHERE id = $1 AND patient_id = $2
   • Return 404, not 403, so ids cannot be probed.

   Test

   • Request patient B’s booking with patient A’s token; expect 404.

   Also check

   • GetInvoice and GetPrescription use the same pattern.

5. D/05

   Executive summary

   One page for the people who sign off: the overall risk, what we found, what it would mean if someone used it, and what to fix first. It is written in plain language, so it can go to a board, a client or a regulator as it is.

   Included

   • The overall risk, in one line
   • Findings counted by severity
   • Business impact, without the jargon
   • The fixes to make first, in order

   Overall risk

   High

   low once F-01 and F-02 are fixed

   Findings

   6

   2 high · 2 medium · 2 low

   Critical

   0

   no finding gives full control

   Effort to fix

   ~4 days

   estimated, for one developer

6. D/06

   Re-test

   Once you have patched, we test each finding again and update the report with its new status. You end with a document that shows where you stand today, ready to share with clients or auditors.

   Included

   • Every finding tested again, with fresh evidence
   • A status for each: fixed, partly fixed or open
   • An updated report and executive summary
   • A check that the fixes opened nothing new

   • F-01 · Booking reads check the ownerfixed
   • F-02 · Reset links expire after 30 minutesfixed
   • F-03 · Login codes limited per IP, not per accountpartly
   • F-04 · Clinic notes are escaped on outputfixed
   • F-05 · Generic error pages in productionfixed
   • F-06 · Security headers still missing on the APIopen

1. 01

   Scope

   What is in, what is out, when we test and who to call if something breaks.

2. 02

   Recon

   We map the attack surface: endpoints, subdomains, versions, people.

3. 03

   Attack

   Authentication, authorisation, injection, business logic — chained the way attackers do.

4. 04

   Report & re-test

   Findings with fixes, a walkthrough with your team, and a re-test once patched.

Testing one web app with its API usually takes two to three weeks from scoping to report, and the re-test follows whenever your fixes are ready. If we find something critical, we call you the same day instead of waiting for the report.

1. Week 1

   Scoping call, written authorisation and signed rules of engagement, then test accounts set up.

2. Days 1–2

   Reconnaissance: endpoints, subdomains, versions and the roles each part of the app supports.

3. Days 3–8

   Hands-on testing of authentication, access control, injection and business logic.

4. Days 9–10

   The report and executive summary, then a walkthrough with your developers.

5. After your fixes

   A re-test of every finding and an updated report showing where you stand.

• The full report

  Every finding with its CVSS rating, evidence, impact and steps to reproduce.

• The executive summary

  One page in plain language for management, clients or regulators.

• Fix guidance

  A concrete fix and a test for each finding, written for your stack.

• The evidence

  Requests, responses and screenshots, archived and handed over securely.

• The re-test report

  The status of every finding after your fixes, with fresh evidence.

• A letter of assessment

  A short signed letter stating what was tested and when, for clients and auditors.

• OWASP WSTG
• OWASP ASVS
• PTES
• Burp Suite
• nmap
• ffuf
• Nuclei
• sqlmap

• Networks & security

  Every office connected, every door locked.

  Explore →

• Reverse engineering

  When the documentation left with the vendor.

  Explore →

• APIs & backends

  The part nobody sees, built to never be noticed.

  Explore →