Most businesses trust their web agency with more than they realise. The agency has access to the hosting environment, the content management system, sometimes email. They write the code that processes customer data and payment information. They often hold admin credentials that could unlock everything.
And most agencies treat security as something that happens after the project is delivered. If it happens at all.
This is not a criticism of web agencies as people. They are often talented, creative, hardworking. But security is a different discipline. It requires a different mindset, different training, and a different way of thinking about what can go wrong. The skill sets genuinely do not overlap the way most clients assume.
What gets missed
The most common security failures in web projects are not dramatic. They are quiet oversights that compound over time.
Outdated plugins and themes are the entry point for the majority of website compromises. A popular plugin has a vulnerability published, and within hours automated scanners are probing every site on the internet that has not patched it yet. Most agencies set up a site, hand it over, and never update it again unless the client pays for ongoing maintenance. Many clients do not.
HTTPS is now table stakes, but the way TLS is configured still matters. Old protocol versions, weak cipher suites, missing security headers. None of these are visible to a client looking at a website. All of them are visible to a scanner or an attacker.
Contact forms, login pages, and any feature that accepts user input is a potential attack surface. SQL injection, cross-site scripting, insecure file uploads. These vulnerabilities have been known and documented for decades and they still appear regularly in agency-built websites because the developer who built the form was thinking about functionality, not security.
The checkbox problem
Security in web projects often gets reduced to a single question: is the site on HTTPS? If yes, the security box is considered ticked. This is like checking whether a building has a front door and concluding it is secure.
A more complete picture includes how user data is stored, whether passwords are properly hashed, what happens to form submissions, whether the admin panel is protected beyond a basic username and password, and whether there are any monitoring or alerting mechanisms in place if something goes wrong.
Most clients have never been asked these questions by their agency. Most agencies have never thought to ask them.
What a secure web build actually looks like
It is not dramatically different from a standard web build. It costs more in thinking time than in tooling. But the mindset is different from the start.
Dependencies are selected carefully and kept updated. Input validation is not an afterthought. Admin access is protected properly. Security headers are configured. The hosting environment is hardened rather than running at defaults. And before launch, someone who was not involved in building the site looks at it from the outside with the specific intent of finding problems.
That last step is the one most agencies skip. It is also the most valuable.
What clients can do
Ask your agency about their security process before you engage them. Not whether the site will be on HTTPS, but how they handle dependency management, how they protect admin access, and what their process is for security testing before launch.
A good agency will have answers. An agency that has not thought about these questions is telling you something important.
Your website is an asset and an attack surface at the same time. The businesses that treat it only as the former are the ones who end up dealing with consequences they never planned for.