Skip to content
◆Service

Secure Web Applications for SMEs

Secure web applications designed and built end-to-end for organisations that cannot justify a full security team.

Security applied at each gate of the build, starting with a threat model before any code exists. Decisions taken at the design gate cost nothing; the same decisions after launch involve a migration.

Smaller organisations rarely have a security team, so security in a web build tends to be deferred until something forces the issue. Usually that force is one of two things: a customer security questionnaire that stalls a sale, or a breach. Both are considerably more expensive than designing the thing properly in the first place, and neither is a good moment to discover that the application was built fast by someone who has since moved on.

The alternative is not exotic. A threat model before any code is written, so the architecture accounts for how it will be attacked. A build against the OWASP Application Security Verification Standard with the OWASP Top 10 closed off by default rather than tested for afterwards. Privacy engineered in, aligned to the Privacy Act 2020, which mostly means collecting less and being deliberate about retention. Then a hardened deployment: a strict content security policy, sensible security headers, and no development conveniences left switched on.

The last part matters most for an SME: a handover with no black boxes. If the application can only be maintained by the person who built it, you have swapped one risk for another. This site is the reference implementation, and it is deliberately checkable, with a strict CSP carrying a per-request nonce, A-grade security headers, and no third-party tracking anywhere.

You might need this if

  • A customer security questionnaire has stalled a sale and nobody can answer it confidently
  • The application was built quickly and no one has reviewed it since launch
  • You handle personal or payment data and there has never been a threat model
  • The developer who built it has left and the deployment is not understood
  • Dependencies have not been updated since the project started

Who it's for

SMEs and founders who need a web application built right the first time, secure, private, and compliant by design.

How the engagement runs

  1. 01

    Threat model and architecture

    Work out who would attack this and how, before a line is written. Decisions made at this stage cost nothing; the same decisions made after launch involve a migration.

  2. 02

    Secure build

    Built against OWASP ASVS, with the Top 10 addressed by design, privacy obligations engineered in, and dependencies chosen with their supply chain in mind.

  3. 03

    Testing and hardening

    Security testing against the threat model, a strict content security policy, security headers, and deployment configuration with the development conveniences removed.

  4. 04

    Handover

    Documentation, dependency update guidance, and a walkthrough, so your team or your next developer can maintain it without reverse-engineering anything.

What's delivered

  • Secure-by-design architecture and threat model before a line is written
  • Build to OWASP ASVS, with the OWASP Top 10 closed off by default
  • Privacy engineered in, aligned to the NZ Privacy Act 2020
  • Hardened deployment with security headers, CSP, and sensible defaults
  • A handover your team can maintain, with no black boxes

Proof point

This site is the reference implementation, with a strict CSP, A-grade security headers, and privacy by design.

Common questions

Can you work with our existing developers rather than replacing them?
Yes, and that is often the better arrangement. Threat modelling, security review, and hardening alongside a team that already knows the domain usually produces a stronger result than handing the whole build to someone new.
We already have an application. Can you review rather than rebuild?
Almost always, and it should be the starting assumption. A review and a hardening pass resolve most situations. I would only recommend rebuilding where the architecture makes a specific class of vulnerability unavoidable, and I would show you why rather than assert it.
What technology stack do you work in?
This site is Next.js and TypeScript, which is a reasonable default for most SME web applications. The security work is not stack-specific though, and the threat modelling, review and hardening apply regardless of what it is built in.
Isn't a penetration test enough?
A penetration test is a point-in-time sample by someone with limited time and no design context. It finds real problems and it cannot find the ones baked into the architecture. Testing complements secure design; it does not substitute for it.

Other services

Get in touch

Let's talk about your security programme

Considering a vCISO, a security strategy and architecture, a SOC uplift, an AI assurance review, or a secure web build? Tell me where you are and where you need to get to.

Discuss an engagementaspera@antan.co.nzLinkedIn (opens in a new tab)