The file nobody meant to publish
An environment file, a database backup, or a version control directory is reachable at a predictable path. Nothing had to be broken; it simply had to be requested.
Cyber · Security Audit & Hardening
Find it before
somebody else does.
A public server tells you a great deal without being asked. Headers, transport configuration, DNS records, exposed files and leaked keys are all readable by anyone — including the people looking for them.
CriticalCYB-05.env exposed at /.env
CriticalCYB-04service key in main.js bundle
HighCYB-10no Content-Security-Policy header
HighCYB-09HSTS not enabled
MediumCYB-17DMARC policy set to none
41/100 Cyber score · capped by open Critical findings
Findings are private by default and never published without written consent.
Quick answer
What does a security audit actually check?
A passive external security audit examines what a server voluntarily reveals to any visitor, without authentication or active probing. This includes security response headers, transport layer configuration and certificate validity, DNS records governing mail authentication, publicly reachable sensitive paths such as environment files or version control directories, credentials accidentally included in client-side code or repository history, and software versions matched against published vulnerability advisories. It does not include anything requiring credentials or active testing, both of which need explicit authorisation. The value of the passive layer is that it identifies the exposures an opportunistic attacker would find first, since these require no skill to discover — only the willingness to look at what is already public.
The problem
The easiest exposures
are the ones still open.
These do not require an attacker with skill. They require an attacker with a list of predictable paths and an afternoon.
The key in the bundle
A service credential reaches client-side JavaScript. It is publicly readable, it grants access regardless of every policy above it, and rotating it later does not undo what was already taken.
The report with no fix path
A scanner produced two hundred findings ranked by tool severity. Nobody could tell which three actually mattered, so nothing was actioned and the report became a filed obligation.
What's included
Four deliverables.
Every finding is verified by hand before it appears. Automated output on its own is not a finding — it is a candidate.
01
Passive external assessment
Security headers, transport configuration, DNS records, publicly reachable paths, leaked secrets and version-matched vulnerabilities, scored against the Standard.
02
Prioritised findings
Ranked by severity and actual exploitability rather than by tool output, so the first three items on the list are genuinely the first three to fix.
03
Remediation path per finding
What to change, where, and what verifies the fix — written for the person who will implement it rather than for the person who commissioned the report.
04
Hardening engagement, optional
Where you want us to make the changes rather than describe them. Priced separately and deliberately, so the audit stays honest instead of becoming a sales instrument.
The engagement
Five steps. Scope first.
Anything beyond passive observation requires verified ownership. That gate sits in the engagement, not in a disclaimer at the bottom of a page.
- 01
Scope
Confirm which properties are in scope and at which tier. Beyond Tier 0 requires ownership verification.
- 02
Scan
Headers, transport, DNS, exposed paths, bundles and full repository history for credentials.
- 03
Verify
Confirm every finding manually. Automated output alone is a candidate, not a finding.
- 04
Prioritise
Rank by severity and exploitability, with a specific fix path attached to each item.
- 05
Harden
Optionally implement, then rescan — demonstrating the change rather than asserting it.
19Cyber rules in the Standard, more than any other pillar
9Classified Critical, because these failures are the least recoverable
59Score cap applied while any Critical finding remains open
Why a leaked key cannot be fixed by rotation alone. When a credential reaches a public bundle or repository history, the correct assumption is that it has been read. Rotation stops future use; it does nothing about access already obtained or data already copied, and it leaves no record of what occurred. Rule CYB-04 therefore requires scanning built bundles and full repository history — not only the current commit — and confirming rotation of anything discovered. The rule is classified Critical because the window between exposure and discovery is typically long and entirely invisible, and because remediation cannot restore the position that existed before.
Source: The Qawex Standard v1.0, rule CYB-04 · Read the Cyber rulesQuestions
Answers, not brochures.
Do you need our permission to run this?
Not for Tier 0, which reads only what a server voluntarily returns to any visitor and is rate-limited and respectful of robots directives. Anything requiring credentials or active probing needs verified domain ownership, and active testing needs a signed scope agreement. We build that gate into the engagement rather than into a disclaimer.
How is this different from a vulnerability scanner?
A scanner produces output; an audit produces findings. Every item is verified manually before it appears, ranked by exploitability rather than by tool severity, and carries a specific remediation path. A list of two hundred unranked items is not more thorough than a list of nine actionable ones — it is less useful.
What if you find something critical?
You are told immediately and privately, before anything is written into a report, with the remediation path attached. Findings are never published, never used in marketing and never shared without written consent — and that holds regardless of whether you become a client.
Do you fix what you find?
If you want us to. Hardening is a separate engagement, priced separately and deliberately so, because an audit that exists to generate remediation work is not an honest audit. Many clients take the findings to their own team, and the report is written for that outcome.
How often should this be repeated?
Configuration drifts, dependencies age and new advisories are published continuously, so a single audit describes one moment. Under a managed package this runs continuously with alerting when a score falls; otherwise, repeating it after any significant infrastructure change is the sensible minimum.
See what is already public.
The Tier 0 assessment runs against any public URL and reports headers, transport, DNS, exposed files and leaked secrets. Free, and private to you.