Penetration Test

The cheapest way to check security is to run automated scanners. They sweep code and services for known patterns, they can run on every deploy, and they cost almost nothing. A fair amount gets caught at that stage: missing input validation, outdated libraries with published flaws, misconfigured headers.

The limit is that a tool finds only what it already knows. Pagedeck ran into that. Someone who arrived through a share link changed one digit at the end of a document URL and another team's document opened. That screen had been marked clean by the automated scan.

The reason was simple. There was no syntactic defect in the code and no known attack pattern in play. One line was missing — the authorization check confirming that the requester was allowed to see that document. A tool does not know the line should be there. That judgment belongs to someone who knows who is supposed to see what in this particular product.

Holes that only appear when a person sets a goal, writes a scenario, and actually knocks are the reason this assessment exists.

It runs in six steps, and skipping the first two turns the assessment into an incident.

1. Pin scope and rules down in writing. Which addresses and accounts may be touched, what must not be done, over what period, and who to contact when something breaks. The must-not list usually includes deleting real customer data and load attacks that take the service down. Without this document the testing side carries legal risk, and the receiving side cannot tell where an assessment ends and an actual intrusion begins. Both sides sign it, and it is the artifact a lawyer asks for if anything goes wrong.
2. Decide how much information to hand over. Starting from outside with nothing, starting with a couple of accounts and documents, or starting with the source code. If the window is two weeks, the middle option is the practical one — start with nothing and the first week goes to finding the entrance, and unlike us an attacker has no deadline. Handing over source code moves the other way and finds more per hour, at the cost of testing from a view no attacker starts from.
3. Write the scenarios. Not by running a tool first, but by starting from what you want to protect. Whether another team's document can be opened, whether a free account can reach paid features, whether a removed member can still get in. Written as sentences they are testable; written as tool names they are not.
4. Knock. Sweep OWASP Top 10, the list of the most frequently exploited web vulnerabilities, as an initial checklist, then move into the permission structure that only exists in this product. The first part overlaps with what tools do; the second is where this assessment earns its money, and where the findings tend to be unique to you.
5. Take the report. Each finding needs four things to be usable: reproduction steps, what could actually be done, severity, and a recommendation. A finding without reproduction steps cannot be fixed — engineering needs to know which requests in which order produced what was seen. Severity matters too, because thirty findings with no ordering get read once and shelved.
6. Fix, then recheck only those findings. That closes one round. Skip the recheck and items marked fixed go a full year without anyone knowing whether they were actually closed.

Four moments fit. After a large structural change; before opening something hard to undo, like payments or permissions; when an enterprise customer requires it as a contract condition; and once a year or so as routine. The third is the most common in practice — Sofia is regularly asked for a recent report while writing enterprise contracts, and some name a maximum age for it, such as twelve months.

Three situations do not fit.

1. Early-stage code changing heavily each week. Get a report and then replace half the screens the following week and half of it is unusable.
2. Basic findings an automated scan would catch still lying around. Bringing people in then spends expensive hours on work a tool does. Clear those first.
3. A budget that covers only two or three screens. With the scope that narrow, a report arrives and everything outside it is still unexamined.

There are three limits. First, the result is a photograph of one moment; a new hole can arrive with the next deploy, so having passed does not mean being safe now. Second, nothing outside scope was looked at — exclude the admin screens and nothing whatsoever has been established about them. Third, the result depends on the skill of the people. Two firms testing the same service produce overlapping but different lists, which makes choosing the firm part of the method rather than an administrative detail.

"The pen test starts next month. Let's finalize the scope document first."

Fix the permitted targets and the prohibited actions before anything begins.

"This finding has no reproduction steps, so we can't fix it."

Something the report needed is missing.

"Passing doesn't mean we're safe. Scope stopped at the payment screens."

Making clear how far the conclusion reaches.

Pagedeck runs one annually and again after any large change to payments or permissions. Theo writes the scope document and Grace approves it. When the report arrives, Theo lays the findings out by severity and puts anything that leaks data or exposes someone else's document into the next deploy. The rest goes on a list with a date attached.

Attaching the date is what makes the difference. Low-severity findings that go unrecorded come back as the same findings in next year's report.

The most common reading is that passing means being safe. Outside specialists knocked and found nothing, so it looks that way. What the assessment reports is narrower: that knocking within a fixed scope over a fixed period turned up this much. Outside the scope and after the test date are not included. A report is evidence about a past state, not a property of the system. Read as a safety certificate, it means nobody looks again at the features added next quarter, and those become the site of the next incident.

The second is that the people who built it can do this themselves. They know the product best, so they ought to find the most. But builders knock inside their own assumptions. Someone who built a screen on the premise that only logged-in users arrive there struggles to think of opening that address without logging in. What outsiders are worth comes less from skill than from the absence of that premise.