Trust & Security

The marketing sites I build, this one included, are static-first: pages are pre-built and served from a global edge network over TLS, not assembled live by a plugin CMS with a database behind it. There is no plugin stack to patch on a Tuesday night and no admin login bolted to the public site. Most of the attack surface that keeps small-business website owners up at night simply is not there.

The same architecture is why these sites stay fast under load. A traffic surge lands on files the edge network already has, so there is nothing to assemble.

Most of website security is a set of instructions the site gives the visitor’s browser. They are invisible, they cost nothing, and a surprising number of small business sites send none of them. Here is what goes out with every build I do, this site included, and what each one actually does.

A content security policy

The browser is told exactly which sources are allowed to run code, load images, or submit a form. If something manages to inject a script from somewhere else, the browser has already been told not to run it.

Strict transport security

The browser refuses to load the site over an insecure connection, even if someone types the address without the s in https. It is remembered for two years and the domain is on the browser preload list.

Frame and form protection

The site can only be framed by my own pages, so it cannot be loaded inside somebody else’s to trick your customers, and a form on your site can only submit back to your site.

Content type and referrer rules

The browser is stopped from guessing that a file is something it is not, and your visitors’ page addresses are not handed to other sites as they click away.

Permissions switched off

Camera, microphone, location, payment and sensor access are turned off at the page level, so nothing on the page can ask for them.

You do not have to take my word for any of it. Paste kootenaymade.ca into securityheaders.com, or run curl -I on the address, and read what the server actually sends back. I would rather you checked. Most agencies would rather you did not, which is the interesting part.

Authentication

Where a project has client areas or dashboards, sign-in runs on dedicated authentication infrastructure (Supabase) with role-based access, never a homegrown password table.

Payments

Card payments are processed by Stripe. I never see or store card numbers, on my projects or my own site.

Forms

Every public form is rate limited and checked on the server, not just in the browser, so a bot that skips your page entirely still gets nowhere. What you type is never written into a log or echoed back into a page.

Email that is actually yours

Where a site sends email, I set up the sending records at launch so your messages are recognised as genuinely from you, and so somebody else cannot send mail pretending to be your business. Most small business domains publish nothing at all, which is why their own invoices land in spam.

Code custody

Every project lives in version control from the first commit. Clients own their code, their content, and their accounts. If we ever part ways, everything comes with you. I build on that principle because I would demand it as a client.

Your domain, your name

The domain is registered to you, with the registrar lock on and two-factor turned on at the sign-off session. Losing a domain is worse than losing a website, because your email goes with it.

Dependencies

The list of third-party code a site depends on is kept short and boring, pinned to exact versions, and checked before every release. Every package added is a party you have decided to trust.

Deployment

Changes ship through a build pipeline with type checks and build gates, not by editing files on a live server. If a build fails its checks, it does not deploy.

This site collects the contact form details you send me, anonymous aggregate analytics, and an advertising pixel from Meta that measures my Facebook and Instagram ads. The privacy policy sets out what the pixel does, including what it passes Meta when you send the contact form. You can turn it off from the bottom of any page.

Some of the providers behind this site (Stripe, Supabase, Vercel, Google, Meta) operate outside Canada, so data they process can be stored or processed outside Canada. I say that here because the privacy policy says it too.

For institutional projects, data location follows the engagement: where a public body requires hosting on its own infrastructure or within specific jurisdictions, the project is built to that requirement and the data-location posture is stated in writing per engagement.

Nobody honest will tell you a website is secure, because secure is not a state anything reaches and stays in. What I can tell you is exactly what I do, which is the list above, and exactly where it stops, which is this.

None of it protects your email account, your phone, your laptop, or your passwords. If somebody learns your email password, a locked-down website does not help. It does not cover your Google account, your social profiles, or your payment processor, all of which live with those companies and are secured by you turning on two-factor and using a password manager. It does not cover what you or your staff choose to publish.

I am a website builder, not a security firm. I hold no security certification, I do not offer penetration testing or security audits, and I would be suspicious of any web designer who told you otherwise. What I offer is a site built to a standard I can describe in full and you can verify yourself, plus one person who answers the phone when something looks wrong.

I use an AI-assisted delivery toolchain, and it runs under written rules: client data enters third-party AI systems only with prior written approval, and every deliverable ships after my own verification. The full policy is public, because a policy that only exists when someone asks is not a policy.

Security questions get answered by the person who built the system, not routed through a ticket queue to someone who has never seen your project. That is the practical meaning of a single accountable builder: when something needs attention, there is no handoff chain to lose it in.

If you have a security question about this site or a project, email hello@kootenaymade.ca. Anything that looks like a vulnerability report gets read first and fixed fast.