Close the obvious doors before they're tested.
CSP and HSTS, secure cookies, rate-limiting, dependency hygiene, and infrastructure hardening — the baseline checklist that takes most teams from “vulnerable” to “adequate” in a single focused sprint.
A free scanner already found the issues. So will an attacker.
Most apps that have never had a security pass are leaking the same handful of giveaways: missing response headers, cookies without the Secure flag, no rate limit on the login form, a library three versions behind a known CVE, a cloud account still on its default settings. None of it is exotic — it's exactly what a free scanner reports in thirty seconds, which is exactly what an opportunistic attacker runs first. Hardening is the unglamorous work of closing those doors. We run a focused pass down a concrete checklist, apply the fixes, commit the config, and document it — so the easy findings are gone and you've gone from “vulnerable” to “adequate” in a single sprint.
The doors are open and you know it.
Each one has the same answer — a focused pass that closes the obvious gaps.
- 01
You've never done a baseline hardening pass
A concrete checklist applied — headers, cookies, limits, baseline — not a vague to-do.
- 02
Free scanners flag basic issues
The easy findings closed, so the obvious attack paths close with them.
- 03
A pen test is on the calendar
The trivial findings cleared first, so the test spends its budget on depth.
- 04
Dependencies sit out of date
An audit and a sane update policy, so a CVE is a small planned fix.
- 05
The cloud account is still on defaults
A baseline pass: MFA, least privilege, no accidental public buckets.
The checklist, actually applied.
High-value fixes first, every one committed and documented.
Headers + cookies
CSP, HSTS, and secure cookie config — the cheap, high-value layer.
Abuse posture
Rate limits, lockouts, and a sane DDoS stance at the edge.
Dependency audit
Known-vulnerable packages found, updated, and kept current.
Cloud baseline
MFA, least privilege, no public buckets, logging on.
Five layers between an attacker and your data.
- 1Headers
- 2Cookies
- 3Rate limit
- 4Dependencies
- 5Baseline
No single control stops everything, so we don't lean on one. Headers blunt whole classes of browser attacks; secure cookies protect the session; rate limits stop the brute-force; an up-to-date dependency tree removes the known CVEs; and a hardened cloud baseline closes the back door. Each layer covers for what the one before it misses.
Tell the browser how to protect your users.
Response headers are the cheapest security you can buy, and the most commonly missing. HSTS forces HTTPS so a downgrade can't strip it. A Content-Security-Policy limits where scripts load from and neutralises whole classes of XSS. X-Frame-Options stops clickjacking, and Referrer-Policy stops leaking your URLs to third parties. We set sensible values, get CSP right without breaking the app, and ship them.
- HSTS, X-Frame-Options, Referrer-Policy set
- Content-Security-Policy tuned to your app
- XSS and clickjacking classes blunted
- Verified against a clean scanner report
Make the session impossible to walk off with.
Most session theft comes down to a cookie that wasn't locked down. We set Secure (HTTPS only), HttpOnly (invisible to JavaScript, so XSS can't read it), and SameSite (so it isn't sent cross-site), add sensible timeouts, and make sure every state-changing request is protected against CSRF — via SameSite or explicit tokens, depending on your stack. Small flags, large reduction in the most common real-world attack paths.
- Secure, HttpOnly, SameSite cookie flags
- Sensible session timeouts and rotation
- CSRF protection on state-changing requests
- Hardened against the common session attacks
Make brute force and abuse not worth it.
An endpoint with no rate limit is an open invitation to credential stuffing, scraping, and abuse — and most apps ship without one. We add limits where they matter (auth, password reset, expensive queries), plus account lockouts and basic bot defence. For volumetric DDoS the right answer is usually a CDN or edge provider in front of the app, so we set that posture up rather than fighting traffic spikes in code.
- Rate limits on auth and expensive routes
- Account lockouts and basic bot defence
- Edge / CDN posture for volumetric DDoS
- Abuse made expensive, not effortless
A focused sprint, end to end.
Run the scan
We start where an attacker would — the same free scanners — to inventory the open doors and rank them by real risk.
Headers + cookies
CSP, HSTS, and the rest applied; cookies locked down with Secure, HttpOnly, and SameSite, plus CSRF protection.
Abuse + DDoS
Rate limits on the endpoints that matter, account lockouts, and an edge posture for volumetric traffic.
Audit dependencies
Known-vulnerable packages found and updated, with a policy so the tree stays current.
Cloud baseline
MFA, least-privilege IAM, no public buckets, encryption and logging on — then document the lot.
The obvious gaps stopped being someone else's problem.
You've never done a baseline pass
Not out of negligence — it just never got prioritised. Now a scanner, a prospect, or a deadline is forcing the issue.
Free scanners flag basic issues
The automated tools already see the open doors. We close them before someone less friendly runs the same scan.
A pen test is coming
Clearing the trivial findings first means the test spends its budget on depth, and the report you show afterwards is cleaner.
Practical controls, applied with judgement.
The things teams ask first.
Close the obvious doors before they're tested.
Tell us what you're running and what's prompting the focus — a scanner's findings, a pen test on the calendar, or just the right instinct. We'll run the baseline hardening pass, clear the easy findings, and leave you measurably harder to attack with the work committed and documented.