Security

A marketing site is a small attack surface that is worth keeping small, and a contact form is worthless if its mail lands in a spam folder. We treat both as engineering floors with verifiable evidence, not as reassurances on a slide.

Surface

Less to attack, by construction

No server to break into

The site is compiled to static files and served from an edge network. There is no application server running day and night, no database reachable from the internet, no admin login page for bots to hammer, and no plugin layer waiting for its next vulnerability announcement. Most of what gets marketing sites hacked simply is not there.

One small dynamic door, guarded

The contact form posts to a single serverless endpoint on the same domain, which validates everything it receives, holds no data store, and does exactly one job. Keeping the dynamic surface this small is a design decision, not an accident, and it is why the rest of the site cannot be taken down by a form.

Headers

Security headers you can read for yourself

Every response the site serves carries a strict header set from day one, and none of it is a secret: open your browser's developer tools on this page and read them.

  • A real content security policy. Scripts run only from the site's own origin plus the few named services the site genuinely uses; each inline script is individually pinned by a cryptographic hash. An injected script is refused by the browser before it executes.
  • Strict transport security. Browsers are told to speak to the site only over an encrypted connection, permanently, so a downgrade attack has nothing to downgrade.
  • No content sniffing, no framing. Responses declare their type and refuse reinterpretation, and the site cannot be loaded inside a hostile page's frame for a clickjacking overlay.
  • A referrer policy that respects visitors. Outbound links do not leak the full address a visitor was reading.
  • Enforced by the test suite. The header set is asserted on every change, so a regression fails the build rather than shipping silently.

Forms

Form defences in layers

01

Humanity checked without friction

A privacy-respecting challenge verifies that the sender is a person, without puzzles to solve and without following visitors around the web. Naive bots are caught by a hidden field only machines fill in, and fast ones by a timer no human submission can beat.

02

Validated where it counts

Everything is validated again on the server: field lengths, formats, and the origin the submission came from. Client-side checks are a courtesy; the server-side ones are the guarantee.

03

Honest failure

A submission we reject gets an honest error and a direct email address, never a thank-you page for a message that was quietly dropped. A visitor with scripts disabled has a working path too.

Mail

The lead actually arrives

The quiet failure mode of contact forms is not spam coming in; it is real mail not getting out. Form mail sent from an unverified domain lands in spam folders, and nobody notices until a customer mentions they never heard back. Every site we run sends from a properly verified sending domain, with the authentication records receiving providers check before trusting a message. Deliverability is verified as part of publishing, so a sending setup that breaks is caught by us at deploy time, not discovered by you a month later in lost enquiries.

Privacy

Private by default, secrets kept out

  • No trackers unless you ask. Nothing third party loads by default, and the only analytics we will fit is cookieless, which also means no consent banner cluttering your first impression. You can verify the absence in the network panel right now.
  • Visitors are not inventory. The site collects nothing beyond what a visitor types into the form to reach you, and that goes to your inbox, not into a marketing database.
  • Secrets never live in the code. Keys and credentials stay in a dedicated secret store and reach the running site as environment configuration. Nothing sensitive is a file in the repository, so nothing sensitive leaks with the code.
  • Deploys leave a trail. Every change to the live site is a reviewed commit with a passing test run behind it, and the previous version is one step away if anything ever needs reverting.
Start a website project [email protected]

Ask us to walk you through any of this on a real deployment. Reach us via the contact form or at [email protected].