A security audit sized for a small web app.
Between a free scanner that returns noise and a certified penetration test you cannot justify yet, there is nothing. This is the thing in between: a person reads your configuration, dependencies, authentication and exposed surface, and hands you a prioritised fix list. Fixed scope, fixed price, quoted before you commit.
What this is not
Putting this first because it decides whether you should keep reading.
- This is not a licensed penetration test. We are not CREST-accredited and not a NACSA-licensed provider. We do not attack your systems.
- It will not satisfy a compliance requirement. If you need PCI-DSS Requirement 11.3, ISO 27001 evidence, SOC 2, or BNM RMiT, you need a certified firm. Ask us and we will point you at one.
- It is not an automated scan. A scanner is one input. The findings that matter — access control between accounts, a reset flow that can be replayed — come from a person reading the thing.
What it is: the review that should happen before any of the above, and usually never has.
Three ways in
Start with the free surface check. It is genuinely useful on its own, and it tells you whether the paid audit is worth your money.
Free surface check
Free
Back within 3 business days
The outside view — what anyone on the internet can already see.
- Transport security and certificate configuration
- Security headers and cookie flags
- Exposed files, directories and backup artefacts
- Known-CVE sweep of the front-end dependencies we can see
- One-page summary of anything that needs attention now
Full audit + proposal
Quoted per scope
Written proposal within 2 business days · fixed price before you commit
Priced by the number of apps, templates and endpoints — and whether we get code access. You see the number before you agree to anything.
The structured review, written up so a developer can work through it.
- Everything in the free surface check
- Authentication and session handling — login, reset, timeout, fixation
- Access control between accounts and roles, including object-level checks
- Injection surface — input handling, queries, templating, file uploads
- Configuration and secret storage, error and debug output
- Dependency audit against known CVEs, including transitive versions
- Third-party scripts and what they can reach
- Prioritised written report — severity, likelihood, and the fix for each
- Walkthrough call so your developer knows exactly what to do
Audit and fixes
Quoted after the audit
Scoped once we know what is actually wrong
We implement the fixes and re-test, rather than handing you a list.
- Everything in the full audit
- We implement the fixes in your site or codebase
- Dependency upgrades with the breaking changes handled
- Re-test of every finding, with before and after
- Handover notes so the next person does not undo it
No retainer, no hourly rate, and no sales call before you get a number.
How it works
- 1
Tell us the scope
The address, roughly how many templates or endpoints, and whether there is a codebase we can read. No call needed to get a number.
- 2
We scope and quote
A written proposal within two business days with a fixed price and an explicit list of what is and is not covered.
- 3
We audit, you get a fix list
Findings ordered by severity and likelihood, each with the actual fix. Anything critical reaches you the day we find it, not in the report.
What we look at
Exposure
What is reachable that should not be — admin paths, staging copies, .git directories, database dumps, backup files, directory listings, verbose error pages that name your stack and its versions.
Authentication
Login, logout, password reset, session lifetime, session fixation, multi-factor if you have it, and what happens at each edge — an expired token, a reused reset link, a concurrent login.
Access control
Whether one account can reach the data of another by changing a number in a URL. This is the single most common serious flaw in small web apps, and automated scanners almost never find it.
Injection surface
How input reaches queries, templates, shell commands and file paths. Uploads: what is accepted, where it lands, and whether it can be executed.
Dependencies
Every library you ship, checked against known CVEs — including the transitive ones you did not choose and probably cannot name.
Configuration and secrets
Where keys live, what is in version control that should not be, what the server discloses about itself, and whether debug mode is off everywhere it matters.
Shipping to an app marketplace?
Marketplaces run their own security review before they will list you, and they reject on the same handful of things every time: secrets left in the package, an over-broad permission scope, unvalidated input crossing a trust boundary, a dependency with a published CVE.
If you are preparing for a marketplace review with a submission deadline, say so when you ask for a quote. We scope against the published requirements rather than against our own checklist, and the fix list comes back ordered by what would get you rejected.
Questions
What is the difference between a security audit and a penetration test?
A penetration test is an attack simulation: a tester tries to break in, usually under a signed scope and often by a certified team. A security audit is a structured review: we read the configuration, the dependencies, the authentication and the exposed surface, and tell you what is wrong and in what order to fix it. The audit finds the common, boring problems that cause most real breaches. The pen test finds what is left. Most small teams need the audit first and have never had one.
Is this a licensed VAPT or a CREST-accredited pen test?
No, and we will not pretend otherwise. We are not a CREST-accredited or NACSA-licensed provider. If your bank, insurer, enterprise customer or regulator requires a certified penetration test — BNM RMiT, PCI-DSS Requirement 11.3, an ISO 27001 audit, a SOC 2 report — you need a licensed firm, and we will tell you that rather than take the work. What we do is the review that should happen long before, and usually has not.
What do you actually check?
Transport and headers, exposed files and directories, authentication and session handling, access control between accounts, injection surface, file upload handling, dependency versions against known CVEs, third-party scripts, error and debug output, and how secrets are stored. The full list is on this page under "What we look at".
Do you need access to our code?
No, but it makes the audit better. We can work entirely from the outside against a running site or app. Given read access to the repository we can also check dependency versions, secret handling and how authentication is actually implemented rather than inferring it from behaviour.
What if you find something serious?
We tell you immediately and privately, before the report and before any invoice, with enough detail to act on it that day. We do not sit on a critical finding to make a report look better. We do not publish, disclose or discuss your findings with anyone.
Will you try to break our site?
No. This is a read-and-review engagement, not an attack. We do not run destructive tests, we do not attempt to exfiltrate data, and we do not load-test anything. If a check could plausibly disrupt a live service, we ask first.
How is it priced?
By scope, stated up front, before you commit. The scope is the number of applications, the number of distinct page templates or endpoints, and whether we get code access. You get a fixed number in a written proposal within two business days. There is no hourly rate and no retainer.
Can you do the fixes too?
Yes. We build software, so the audit lands as a fix list a developer can action — or we implement it ourselves and re-test. That is the third tier.
We are pre-launch. Is it too early?
That is the best time. Fixing an authentication design before it has users is an afternoon. Fixing it afterwards is a migration, a forced password reset and an awkward email. If you are shipping to an app marketplace with its own security review, this is also the point to catch what that review would reject.
Start with the free surface check
Tell us the address and roughly what we would be looking at. If anything urgent turns up in the free check, we will tell you straight away rather than waiting for a report.