Website security audit, brochure site, store or CMS.
A public website is exposed around the clock, and most of what hits it is aimed at nobody in particular. It sweeps, it finds, it comes back. This audit looks at your site the way an attacker does: from the outside, without documentation, hunting for the gap between what you think you published and what is actually reachable.
Nobody is out to get you. That is the problem.
The question I hear most often is "why us?". The answer is almost always the same: no particular reason. The overwhelming majority of public website compromises target nobody in particular. Bots crawl the web continuously, test known versions, the usual admin paths and the files left lying at the root, and write down whatever answers.
A site caught in that net is rarely stripped of data it never had. It becomes a relay: phishing pages hosted on your domain, redirects to counterfeit shops, fraudulent mail sent in your name. The cost is not the theft. It is the cleanup, the domain on a blocklist, and the months of search ranking you spend rebuilding.
The second case is deliberate and far more expensive: somebody wants your customer area, your orders, your contact database. A bot is no longer enough there, it takes a person. And a person always finds what a bot cannot: the form that accepts a reference that is not yours, the order tracking page that works without logging in, the staging subdomain nobody switched off after the redesign.
What I look at.
A public website is not just the pages you commissioned. It is everything that accumulated around them.
- Actual exposure: forgotten subdomains, staging environments still online, older versions of the site nobody ever took down.
- Hosting configuration: security headers, cookies, TLS, directory listing, backup files and archives left reachable.
- CMS and plugins: versions, components abandoned by their author, default settings never hardened, an admin panel open to the entire internet.
- Forms: contact, quote, signup, search. Injection, mail relaying by a third party, no rate limit, address disclosure.
- Customer area: account creation, password reset, and whether one customer can reach another customer's orders and documents.
- Checkout flow: tampering with amounts and quantities, replayable discount codes, orders confirmed without ever passing the payment step.
- File uploads: attachments, profile pictures, documents. Whether the type is genuinely checked, where the file lands, and whether it can execute.
- Custom development: this is where the flaws that exist nowhere else live, and therefore in no signature database either.
How an engagement runs.
Scoping and authorization
We put in writing what is in scope and what is out, the window during which I may test, and who to reach if something critical surfaces. An NDA is signed before you send me a single technical detail.
Mapping the exposure
Before testing anything, I establish what is genuinely reachable from the internet under your name. This step turns up something nobody had in mind almost every time: a staging subdomain, an old store, an internal tool left public.
Sweep of the public surface
Configuration, headers, CMS, plugins, forms. This part leans on tooling so nothing mechanical is missed, but every result is confirmed by hand. A tool that reports fifty problems invented forty-five of them.
Manual work on the journeys
The core of the engagement. I create accounts, place orders, tamper with the parameters the interface is not supposed to let anyone touch, and check whether the server accepts them. This is the step that finds what no scanner will.
Report and walkthrough
Every flaw is ranked by what it would actually cost you, not by a generic score. You get the proof, the steps to reproduce, and the fix. An hour-long session takes your team through all of it.
Retest
Once the fixes are deployed, I replay the relevant tests and confirm in writing what is genuinely closed. Part of the engagement, not billed separately.
What it looks like in practice.
Real findings, reported and fixed. Clients and perimeters are never disclosed.
Website or application? Not the same engagement.
Both services exist because they are not hunting for the same thing. Here is how to settle it in one sentence.
It is a website
Visitors read, fill in a form, buy, and perhaps log into a simple customer area. Most of the risk sits in exposure, configuration and the parts you did not write yourself. That is this page.
It is an application
Users log in to get work done: several roles, overlapping permissions, business flows. The risk shifts to logic and permissions, and needs a different depth of testing.
Common questions.
My site is a brochure site. Do I really have anything worth stealing?
Two things, yes. Your reputation first: a compromised brochure site gets used to host phishing pages or redirect your visitors, and Google flags it in red in its results within hours. Your infrastructure second: the server hosting the brochure site often hosts the mail, an extranet or the backups. The attacker is not after your data, they are after a machine.
How long will the site be down during the audit?
It will not be. I run no denial of service and no load testing, and I never perform a destructive action on real data. Requests are spaced out so the server never feels them. If any step carries the slightest risk for production, I tell you first and we decide together.
Do you need access to my hosting?
Not for the audit itself: I test from the outside, the way an attacker does. User accounts help if there is a customer area or a store, and read access to the code speeds up the custom development part considerably. None of it is required to start.
My agency already installed a web application firewall. Is that enough?
A WAF filters known, generic attacks, which clears out the automated background noise. It cannot see that a quote form accepts an order reference belonging to someone else, because from its point of view that request is entirely legitimate. It reduces volume, not real risk.
What do I do with the fixes afterwards?
Every vulnerability in the report comes with the steps to fix it, written so you can forward it as-is to your agency or your developer. Once the fixes are live, I replay the relevant tests. That retest is part of the engagement, not a separate line on the invoice.
Other services.
API security audit
If your site relies on an API for its forms, basket or customer area, that API enforces its own rules and is tested separately.
Read moreAuthentication and access control
If your customer area distinguishes several kinds of user, the question becomes who can actually reach what.
Read moreHave your website audited.
Send me the address, tell me whether there is a customer area or a store, and whether anything was custom-built. I come back with a scope and a quote. First conversation with no commitment, full confidentiality.