Penetration testing on web apps, portals and corporate networks. Not an automated scan with a badge at the end: someone genuinely trying to get in, using the same techniques as a person who would do it to steal, then writing up what they found in language you can hand to your supplier.
pentest --scope "app + api" --mode grey-box
surface mapped ......... 148 endpoints
login attempts ......... no rate limiting found
authorisation checks ... 1 critical flaw
[ok] report delivered in 5 working days
pentest --retest
a second pass after your fixes: included
waiting
$ ./pentest --target "your system"
A penetration test is not an automated scan with a badge at the end. It is someone genuinely trying to get in, using the same techniques as a person who would do it to steal — then writing up what they found in language you can hand to your supplier.
Changing one number in the address opened another company's documents. It is the commonest flaw we find, and almost nobody has ever looked for it.
API keys and passwords inside the repository or inside the JavaScript served to the browser. Anyone who knows where to look will find them.
The login form accepted unlimited attempts: a weak password falls in minutes.
A stolen login stays valid forever. People who left the company can still get in.
Components with known, already-published vulnerabilities. No attack required: just reading the advisory.
None of these is theoretical: they are the five we find most often. The report says where it is, how we got there and what to do — with a free retest after you have fixed it.
// when you need it
Not everyone needs it to the same degree. But recognise three of these and the cost of not looking has already passed the cost of a test.
// what we actually do
A serious test differs from a fake one in exactly one way: the fake one produces a list of automated warnings, this one produces a path someone walked.
We map the exposed surface: domains, subdomains, endpoints, forgotten services left running for years. Half of all intrusions start from something nobody remembered was online.
We genuinely try the routes: authorisation that can be sidestepped, sessions that can be reused, other people’s data reachable by changing a number. We agree limits and hours beforehand, and we never touch real data.
One part for whoever decides — what you are exposed to, how bad it is, what to fix first. One part for whoever fixes it, with requests, responses and steps to reproduce. Without the second, the first cannot be acted on.
Once you have fixed things we come back to the same points and verify. It is the part almost nobody includes, and the only one that proves the problem is actually closed.
// how we get there
A penetration test without a signed mandate is not a test: it is a crime. It is the first thing we put on the table, and without it we do not start.
We write down what is in and what is out, during which hours, with which limits. Signed by whoever has the authority to authorise it — not by whoever runs the system, by whoever owns it.
We build the inventory of what is reachable. This is often where the first surprise appears: a staging environment left open, an old subdomain still alive.
Critical flaws get reported straight away, not at delivery: if we find a door open onto your customers’ data, you know that same day.
Delivery of the report with priorities and remediation steps, and after your fixes we come back and check the same points.
// a piece of a report
This is the shape things take in the report: what we sent, what answered, and where the point is. It is also the flaw we find most often.
report 04 · missing authorisation check · high severity
# The session belongs to a real user: they logged in\n# normally. Only the number in the address changes.\n\nGET /api/documenti/4187 HTTP/2\nHost: portale.esempio.it\nCookie: sessione=8f2a91c4d7e0\n\nHTTP/2 200 OK\nContent-Type: application/json\n\n{\n "id": 4187,\n "cliente": "another company",\n "file": "contratto-firmato.pdf",\n "url": "https://portale.esempio.it/media/9f1c2b.pdf"\n}// The code that answered 200.\n\nfunction documento(int $id): ?array\n{\n // There is a check, and at first glance it is the right one:\n // without a valid session you do not get past here.\n if (!utente_autenticato()) {\n return null;\n }\n\n // But the question this line answers is\n // "does document 4187 exist?" — and not\n // "does document 4187 belong to whoever is asking?".\n return db()->riga(\n 'SELECT * FROM documenti WHERE id = ?',\n [$id]\n );\n}// The same function, with the owner inside the question.\n\nfunction documento(int $id): ?array\n{\n $utente = utente_autenticato();\n if (!$utente) {\n return null;\n }\n\n // Now the line asks both things at once, and\n // somebody else's document is not "forbidden": it does not exist.\n // No second check to remember elsewhere, because\n // there is no elsewhere left to forget it in.\n return db()->riga(\n 'SELECT * FROM documenti WHERE id = ? AND cliente_id = ?',\n [$id, $utente->cliente_id]\n );\n}The fix does not add a check: it removes the possibility of forgetting one. As long as authorisation is an if written next to the query, sooner or later somebody will write a new query without that if beside it. Put inside the query, the wrong question can no longer be asked — and anyone trying a number at random gets a 404, so they do not even learn that the number corresponds to anything.
$ cat stack.json
$ ./domande --frequenti
Only with a written mandate from whoever owns the system, defining scope, hours and limits. It is the first thing we prepare, and without it we do not begin: an unauthorised penetration test is a crime, for us and for whoever commissioned it.
Destructive tests — the ones that can take a service down — happen only on request and on agreed environments, within a declared window. On production systems we work non-destructively and we do not touch real data.
A test on a mid-sized web app runs 5 to 10 working days including the report. Reconnaissance takes longer than people expect: it is the part that decides the quality of everything after it.
A report in two parts: one for decision-makers, with risk and priorities, and a technical one with steps to reproduce each flaw. Plus a call to read it together, because a PDF handed over and left alone ends up in a folder.
If it collects data about people, yes — and not because of size: the automated scanners hunting for flaws do not check your turnover first. If it is a brochure site with no data and no login, the honest answer is usually that updates and backups are enough.
Security is not a state, it is maintenance: updates, access reviews, and a fresh test whenever something significant changes. The report says how often it makes sense to repeat it in your case.
fymera init --project "yours"
Thirty minutes on video to understand the scope. If the right answer is "update everything and rate-limit your logins", we will say that instead of selling you a test.
