Penetration testing basics

01Authorisation first: the legal and ethical line

The difference between a penetration tester and a criminal is permission. Accessing a computer system without authorisation is a crime in most countries, including under laws like the UK Computer Misuse Act and the US Computer Fraud and Abuse Act, even if you 'only looked' and meant well. Before any testing, a professional gets a signed authorisation from someone who actually owns the systems, plus agreed rules of engagement. Cloud and SaaS platforms add a second layer: your contract with the provider. Most major clouds allow customers to test their own resources within published policies, but forbid things like denial-of-service tests or touching shared infrastructure. Bug bounty programmes are a form of permission too, but only for the assets and techniques they list. If something is out of scope, it stays untouched, even when it looks vulnerable.

• Only test what you own or are explicitly authorised in writing to test.
• Respect scope, time windows and banned techniques exactly.
• Stop and report immediately if you touch real personal data or find signs of a real breach.
• Practise on deliberately vulnerable labs, never on random sites.

02Types of tests and what they answer

Tests differ by target and by how much the tester knows. A black-box test starts with almost no information, like an outside attacker. A grey-box test gives the tester normal user accounts and some documentation, which is the most efficient choice for web apps because time goes into real flaws instead of guessing. A white-box test includes source code and architecture, combining review with testing. Targets vary too: external network, internal network, web application, API, mobile app, cloud configuration, or people (phishing and social engineering, which needs extra legal and HR care). A red-team exercise is different again: a longer, goal-driven simulation that also tests whether the defenders notice. Pick the type that matches the question the business is asking, not the most dramatic one.

• Vulnerability scan: automated, broad, shallow; finds known issues.
• Penetration test: time-boxed, human-led, proves real impact within scope.
• Red team: goal-based, stealthy, tests detection and response as well.

03The methodology: from scope to report

Good testers follow a repeatable method so nothing important is skipped. The Penetration Testing Execution Standard (PTES) describes seven phases, and the OWASP Web Security Testing Guide (WSTG) gives a detailed checklist for web applications. In practice: pre-engagement (scope, permissions, contacts, emergency stop procedure), reconnaissance (what exists: hosts, subdomains, endpoints, technologies), threat modelling (what would hurt this business most), vulnerability analysis (manual testing plus tools), careful exploitation to confirm real impact, post-exploitation only as far as the rules allow, and reporting. Throughout, the tester keeps detailed notes and timestamps, so every finding can be reproduced and every action can be explained if something unexpected happens on the target.

• Pre-engagement, intelligence gathering, threat modelling, vulnerability analysis.
• Exploitation, post-exploitation, reporting (the seven PTES phases).
• Use the WSTG and OWASP Top 10 as coverage checklists for web apps.

04Tools of the trade

Tools support judgement; they do not replace it. An intercepting proxy sits between your browser and the application so you can see and modify every request: Burp Suite (Community and Professional editions) and ZAP (the open-source proxy and scanner formerly known as OWASP ZAP) are the standards. Nmap maps open ports and services on hosts you are allowed to scan. Browser developer tools reveal API calls, tokens and client-side logic. Dependency and container scanners find known vulnerable components. For practice, use intentionally vulnerable targets such as OWASP Juice Shop or DVWA running locally. The example below starts Juice Shop on your own machine, giving you a legal lab to learn the proxy workflow on.

1# A legal practice target, running only on your own machine
2docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop
3 
4# Discover services on a host you own (here: your own lab VM)
5nmap -sV -Pn 192.168.56.10
6 
7# Baseline passive scan with ZAP against your local lab app
8docker run --rm --network host -t zaproxy/zap-stable \
9  zap-baseline.py -t http://127.0.0.1:3000

05Where real findings come from

Most serious web findings are not exotic. They are broken access control (user A can read user B's order by changing an ID), weak authentication flows (password reset tokens that never expire), missing rate limits, injection where input reaches a query or command unsafely, insecure direct file access, exposed admin panels, secrets in front-end bundles, and misconfigured cloud storage. Business-logic flaws are the tester's speciality: applying a discount twice, paying in one currency and refunding in another, skipping a step in a checkout flow. These require understanding what the application is supposed to do, which is why grey-box testing with real accounts and a short product walkthrough is so productive. Confirm impact with the smallest safe proof, such as reading your own second test account's data, not a real customer's.

06Writing a report people can act on

The report is the product. Executives need a one-page summary: overall risk, the few issues that matter most, and what to do next. Engineers need each finding with a title, severity, affected component, clear reproduction steps, evidence (requests, responses, screenshots with sensitive data masked), impact in business terms and a specific fix. Rate severity consistently, for example with CVSS plus a note on business context, because a medium technical issue on a payment flow can matter more than a high one on a test server. Include what was in scope, what was not, and what was not tested due to time. Offer a retest: a finding is only closed when someone has verified the fix.

• Executive summary, scope and method, findings, appendices.
• Each finding: severity, steps, evidence, impact, remediation, references.
• Mask any personal data and secrets in evidence.

07Access control testing at scale

Broken access control is the most common serious web finding, and it is systematic, not random. The efficient approach is a matrix: list every endpoint (from the proxy history or an OpenAPI file) against every role and tenant, then replay each request with the wrong identity. Proxy extensions can automatically resend each request with a lower-privilege session and flag responses that look the same. Check horizontal access (user A to user B), vertical access (user to admin), and multi-tenant isolation (company A to company B). Also check indirect paths: exports, file downloads, websockets, GraphQL fields, background job results and webhooks. In the report, point at the missing central check rather than listing fifty endpoints, because the fix belongs in shared middleware or a query scope.

08APIs, mobile apps and modern front ends

Single-page apps and mobile apps move logic to the client, but the server must still enforce every rule. Testers read the API traffic, not the UI: hidden fields, admin-only properties accepted on update (mass assignment), predictable IDs, excessive data in responses that the UI simply does not display. For mobile, testers inspect traffic through a proxy on a test device, check certificate validation and look for secrets or API keys in the app bundle. Token handling matters: where tokens are stored, how long they live, whether refresh tokens rotate and whether logout actually revokes anything. The OWASP API Security Top 10 and the mobile testing guide (MASTG) extend the web checklist for these targets.

09Testing safely in shared and production environments

Real systems have real users. Rate-limit your own tools, avoid destructive actions (deleting records, sending mass emails, triggering payments) unless the rules explicitly allow them in a sandbox, and use payment provider test modes. Watch for side effects: a form fuzzed with thousands of inputs may send thousands of notifications. When testing cloud configurations, read-only audit roles are often enough to find misconfigured storage, overly broad IAM policies or exposed snapshots without touching data. Keep an emergency channel open with the system owner during the test window, and stop immediately if the service degrades.

10From findings to a better development process

A mature team uses each report to remove whole classes of bugs. Group findings by root cause: missing authorisation middleware, unsafe query building, inconsistent input validation, secrets management. For each class, add a durable control: a framework-level default, a lint rule, a test helper that checks the 'wrong user' case for every endpoint, or a CI scanner. Track time-to-fix by severity as a metric. Feed recurring patterns into code review checklists and onboarding. Over a few cycles, pentest reports should shift from basic access-control bugs to subtle logic issues, which is a sign the process is working.