Why your web partner should understand security, not outsource it
Why security is a property of how a site is built and run, not a service added afterwards, and the questions that show whether a partner understands it.
The short answer
Security is not a service bought after a website is built. It is a property of how the site is built and run, decided in a hundred small choices: where the keys live, whether permissions are checked on the server, how old the dependencies are, what a form does with the data it receives, whether uploads can execute, what headers are set, how small the attack surface is. Most security failures on business websites were built in, and no scanner purchased afterwards removes them. A partner who understands security builds it in as a habit and asks, at every decision, what could go wrong. Specialists have a real role for penetration tests and regulated audits, and a good partner welcomes them. The everyday security of the site is the builder’s job, and a partner who delegates it has delegated the thing they most control.
Built in versus bolted on
| Built in by the partner | Bolted on afterwards |
|---|---|
| Secrets in platform configuration; nothing in the front end | A scan that finds the key in the JavaScript, months later |
| Permissions enforced on the server for every request | A penetration test that finds the page anyone can open |
| Lock file, advisories, updates within days | A report listing forty vulnerable packages |
| Uploads validated by content, stored outside execution | A web shell in the media folder |
| Forms routed on a short documented path | A data map drawn after the breach |
| Headers set at the platform and tested per deploy | A header checker with red marks |
| Static architecture; no public admin; small surface | A security plugin on a platform with fifty plugins |
| Monitoring with alerts to a person | A customer’s email about the casino page |
Five questions for the first meeting
- “Where do secrets live, and can any of them reach the browser?” Expect: platform configuration, never the front end, checked in the pipeline.
- “How are permissions checked on every request?” Expect: server-side, centrally, with a test that fails if a check is missing.
- “How often are dependencies updated, and how is it verified?” Expect: security fixes within days, monthly routine, advisories in the pipeline, listed in the report.
- “Which security headers are set, and how are they tested?” Expect: a named set at the platform, checked on every deploy.
- “What is monitored, and who is alerted at 2 a.m.?” Expect: uptime, errors, forms, certificates, security signals, a named person.
Where specialists belong
A penetration test by an independent party before a major launch and periodically after. A regulated audit where the sector requires it. Incident response expertise for a serious breach. Advice on specific compliance regimes. A partner who understands security asks for these at the right moments and acts on their findings. What the specialist cannot do is be present at the hundred small decisions that make the site secure or not; that is the builder, every day.
What this means for you
Choose a partner who builds security in and can answer the five questions with mechanisms, and who welcomes specialists for tests and audits. The everyday security of your site is decided in how it is built and run; a partner who understands that protects you at every decision, and one who delegates it protects you only after the fact.
Frequently asked questions
Is it not better to have a security specialist handle security?
For a penetration test or a regulated audit, yes, and a good partner welcomes both. For the everyday security of the site, no: the decisions that make a site secure are made while building it, in how secrets are handled, how permissions are checked, which dependencies are chosen and how forms route data. A specialist who arrives afterwards can find the problems; only the builder can avoid creating them.
How do we know if our partner understands security?
Ask five questions: where do secrets live and can any reach the browser; how are permissions checked on every request; how often are dependencies updated and how is it verified; what security headers are set and how are they tested; what is monitored and who is alerted. Specific answers with mechanisms mean understanding. Reassurance without mechanisms means delegation to hope.
Does building securely cost more?
Slightly at first and much less over time. Secrets in configuration, permission checks in one central place, a lock file with advisories, headers set once at the platform, a static architecture with a small surface: each is a habit rather than a project, and each prevents incidents that cost far more than the habit. Security built in is cheaper than security bolted on and incomparably cheaper than the breach.
Sources
- OWASP Top 10 (accessed 2026-09-12)