Security
Security is included, not an upgrade
Every site we build and look after ships with hardened HTTPS, security response headers, blocked source and backup files, loopback-only admin panels, session hardening and per-IP login lockout. It is part of delivery, not a line item you buy back.
Applied by default
The measures below are in place on the sites we run today, not on a roadmap.
HTTPS enforced, and remembered
Every site redirects HTTP to HTTPS at the edge, and sends HSTS with a one-year max-age so a browser refuses to fall back to plain HTTP. Apex and www are resolved to a single canonical host with a 301.
Security response headers on every response
HSTS, X-Content-Type-Options: nosniff, X-Frame-Options, Referrer-Policy and Permissions-Policy are applied to all pages — including error and redirect responses, which is where they are usually forgotten.
Source, backup and secret files blocked
A deny rule covers .env, .git, .ssh, editor and registry files, plus backup and archive extensions (bak, sql, sqlite, db, zip, tar, gz, log, sh, conf, pem, key and others) — including the dated copies people leave behind, like config.php.bak-20260910.
Content-Security-Policy where it can be done safely
A CSP that names the exact script, style, image and connection sources is applied on sites whose third-party dependencies are known and small — including object-src none, frame-ancestors self and base-uri self. Where a page still relies on inline scripts that cannot be externalised without breaking it, we say the CSP is not there yet rather than shipping a token policy that only looks reassuring.
Admin interfaces protected, not just hidden
Control panels and internal tools listen on loopback only, so reaching them requires an SSH tunnel from an authorised machine. Where an admin route has to stay reachable from the internet, it is put behind an additional authentication layer before the application login ever sees the request.
Sessions that survive a stolen cookie poorly
Admin session cookies are set HttpOnly, Secure and SameSite=Lax. The session is cleared and a fresh CSRF token issued on successful login, so a pre-set session cannot be reused. The post-login redirect target is restricted to same-site relative paths.
Brute-force lockout per IP
Repeated failed admin logins lock that IP out and answer with HTTP 429. Thresholds and lock duration are configured per site and are deliberately not published here; if you are a client doing a technical review, ask and we will walk you through the configuration.
Secrets out of the source tree
Application signing keys and admin credentials are read from environment files with restrictive permissions rather than committed defaults. A predictable default session key is treated as a defect to be fixed, not a placeholder to leave in place.
Periodic probe review, not real-time blocking
Scheduled jobs read the site logs, score each source address on behaviour — distinct unopenable paths, sensitive-path hits, credential-dictionary shape — and drop the clearly hostile ones at the firewall. They also verify claimed crawler identities against their published PTR records and block the ones that resolve to somebody else.
How to verify any of this in two minutes
These commands work against any site, ours or a competitor's. We would rather you run them than read another claim.
Response headers
curl -sI https://example.com/ | grep -i -E "strict-transport|x-content-type|x-frame|referrer-policy|permissions-policy"
HTTPS is enforced, not optional
curl -sI http://example.com/ | head -1 — expect a 301, and a Location pointing at https.
A single canonical host
curl -sI https://www.example.com/ | head -2 — expect a 301 to the apex (or the reverse), never two hosts both answering 200.
Source and backup files are not served
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/.env — expect 403 or 404. A 200 here is a real finding.
Included on every build, at no extra cost
Security on a small studio budget usually means a plugin and a hope. Here is what is actually in place.
Hardened server configuration
TLS 1.2/1.3 only, server version strings suppressed, request-rate limits on login and API routes, a WAF rule for path-traversal and command-injection patterns, and hotlink protection with a crawler allowlist so real search engines never get blocked by it.
Automated crawler identity verification
Every claimed crawler is checked against its published PTR records. Impersonators get blocked at the firewall automatically; legitimate crawlers are released even when they publish no PTR — a deliberate trade that has kept false positives at zero.
Behavioural probe detection
Addresses are scored on behaviour — how many distinct unopenable paths, how many sensitive-path hits, credential-dictionary shape, backdoor probing on non-PHP sites — and the clearly hostile ones are dropped automatically.
Alerting with a human on the end
Findings are pushed to a monitored channel with the evidence attached: which address, which paths, what the traffic looked like. Alerts that matter reach a person the same day.
Data minimisation by design
Payment details never touch your server — the gateway holds them. Stored data is limited to what the product genuinely needs, which is the cheapest way to make a breach uninteresting.
Independent log-keeping
Site logs are kept and rotated separately from the application, so there is a record of what happened even if the application itself is compromised. Log volume is managed, not left to fill the disk.
Why it is built in rather than added on
The cheapest moment to get security right is while the site is being built
Security as part of the build, not a separate project
You are not buying a security product. You are hiring a studio that treats it as part of the job.It costs less than retrofitting
Headers, access rules, session handling and safe defaults are configuration, not a project. Bolt-on security work afterwards costs multiples of that and usually misses the parts nobody looks at twice.
It compounds with your visibility work
The same crawler-verification layer that blocks impersonators is what keeps your AI and search visibility data trustworthy. Without it you are measuring traffic from sources you cannot identify.
It survives the handover
Everything is documented in the handover pack: what is configured, where, and how to change it. Your own team inherits a protected site rather than a black box.
Want your current site checked against this list?
Send us the URL. We will run the checks above against it and tell you what fails, including the parts we cannot fix for free.No charge for the read-out.