Penetration test (pentest)
What is a penetration test (pentest)?
A penetration test, or pentest, is a controlled attack on a website or an application, carried out with the owner’s permission to show which weaknesses can actually be used. Unlike an automated scan, a tester chains findings together until they reach real data, someone else’s orders or an administrator account. What you get is a report: every finding with evidence, a severity rating and an order of work.
Example
A company about to open a portal where 400 customers see their own invoices books a pentest before launch. Three things are agreed first: the scope (the portal domain and the customer login), the window, and a rule that no real data changes. The tester is given two test accounts, which makes it a grey-box test: they know what an ordinary user knows. From there:
- An old component answers differently for known and unknown usernames, so usernames can be collected one at a time.
- One account still works with the password it was set up with.
- The document upload field checks the file extension and nothing else, so a file containing code goes through.
- Opened in a browser, that file runs commands on the server and reaches the database with every invoice in it.
None of the four steps is critical on its own. Chained, they are full access to the data, and chaining is what separates a pentest from an automated scan.
Scan or pentest
A vulnerability scan is a tool. It crawls the site, compares component versions against databases of known flaws and returns a list. It is quick and worth running often, but it cannot tell a real finding from a theoretical one and it never combines two weaknesses into one attack. A pentest is manual work over agreed days and it goes after logic: can one customer open another customer’s invoice, can a price change on the way to payment, what does the API do with a value the interface would never send.
Why it matters for a business
A pentest turns “is the site secure?” into a list with severity and an order of work. The report also travels: larger clients and public tenders increasingly ask for evidence that a system has been tested, and GDPR asks you to test your measures regularly, not only to install them. The expensive findings are rarely exotic. Another customer’s invoice, reachable by editing one number in the address, is the classic that an automated tool walks straight past.
What to ask
- What is in scope: the public site only, or also the admin, the API, the mobile app and the staging copy?
- Black-box (the address only) or grey-box (accounts and documentation)? With accounts, the same days cover more ground.
- Does the test run against a copy or the live site, and what happens if something goes down?
- What is in the report: evidence for each finding, a severity rating and the steps to fix it?
- Is a retest after the fixes included, and when does it happen?
On our services this is called website security testing; “pentest” is the trade name developers and auditors use.