Security

Making a site survive the automated traffic every public site receives, and cleaning up properly when something has already got in.

Every public site is scanned continuously by automated tools looking for known weaknesses. This is not targeted and it is not personal — it is the background traffic of the internet, and it starts the day the domain resolves.

Most compromises are not clever. They are an out-of-date component, a form that trusts its input, a password reused somewhere else, or a credential committed to a repository. The defences are correspondingly unglamorous and effective.

What you get

  • A review of how input is validated and how output is escaped, across the whole codebase
  • SQL converted to prepared statements with bound parameters
  • CSRF protection and hardened sessions on anything that changes state
  • Security headers including a Content Security Policy that is enforced rather than merely present
  • Spam and abuse controls on public forms that do not reject genuine enquiries
  • A check for credentials committed to version control — and if any are found, what to do about it
  • After an incident: cleanup, and a written account of how it happened

How the work is done

Validate input, escape output

Two rules, applied consistently, prevent most of what actually happens. Escaping data on the way in rather than on the way out is a common mistake: it corrupts your data and protects nothing.

Assume the attacker is a script

Defences are designed against automated traffic, because that is what almost all of it is. A rate limit that a bot defeats by discarding a cookie is not a rate limit.

Do not block real customers

Spam filters built on keyword lists reject genuine enquiries — someone describing their loan origination system, or pasting a link to the site they need help with. The controls have to be chosen so that legitimate messages get through.

Rotate, do not just delete

A password committed to a repository is not fixed by deleting the file. It stays in the history. The only fix is to change the credential.

What this does not cover

This covers web application and server security. It is not penetration testing, formal compliance certification, or incident response for a breach involving personal data at scale — that needs specialist legal and forensic help, and the right advice is to get it.

Questions

Nobody would target us. Are we really at risk?

Almost all of it is untargeted. Automated scanners look for known weaknesses across every reachable address, and they do not check whether the business is interesting first.

We were hacked and it was cleaned up. Is that enough?

Only if the way in was found and closed. Cleanup without diagnosis usually means the same access is used again a few weeks later.

Do we need a Content Security Policy?

It is one of the highest-value headers available, and it is genuinely fiddly on a site full of third-party scripts. Whether it is worth the effort depends on what the site does — and that is a real answer, not a sales one.

Related

Legacy System Modernization

Bringing an old but working system onto supported PHP and database versions without a rewrite and without losing behaviour people depend on.

Have a system that needs building or fixing?

Describe the problem and you will get a direct answer about whether it is worth doing, roughly what it involves, and what it would take.

Start a conversation