05 · Operate
Website security
No website is fully secure, and any supplier who tells you otherwise has told you something useful about them. What is achievable is a meaningful reduction in risk: fewer ways in, less damage if someone gets in, and faster recovery when something goes wrong.
Most compromises we are called in after were not sophisticated. They were an unpatched plugin, a shared administrator password, or an exposed backup file.
Common exposures
- CMS core, themes or plugins running versions with published vulnerabilities.
- Administrator accounts shared between people, without multi-factor authentication.
- Former staff and former suppliers still holding active access.
- Backups that exist but have never been restored, so nobody knows if they work.
- Credentials committed to a repository or stored in a configuration file in the web root.
- No security headers, and TLS configured once and never reviewed.
- A staging environment publicly reachable with production data in it.
- Nobody assigned to watch for or apply security updates.
What we do
Security audits
A review of the application, its dependencies, its configuration and its access model against known vulnerability classes, with findings prioritised by exploitability and impact.
Hardening
Server and application configuration, security response headers, Content Security Policy, TLS configuration, file permissions, and removing the default exposures most platforms ship with.
Dependency and patch management
Inventory of what you depend on, monitoring for published vulnerabilities, and a tested update process – the single highest-value ongoing security activity for most sites.
Access control
Least-privilege roles, multi-factor authentication, removal of dormant and shared accounts, secrets management outside the codebase, and a documented offboarding process.
Backup and recovery
Backups that are automated, stored separately from the live environment, and – critically – tested by restoring them. An untested backup is a hope, not a control.
Form and abuse protection
Rate limiting, honeypot and server-side validation on public forms. We avoid puzzle-based CAPTCHA, which fails accessibility criteria and stops determined abuse less well than the alternatives.
Incident response support
Where a site has been compromised: containment, assessment, clean-up, restoration and closing the route that was used.
Diagram
How we approach security
-
Reduce the attack surface Every plugin, integration, script and open endpoint is a way in. Removing what is not needed is cheaper and more effective than defending it.
-
Assume compromise is possible Design so that a compromise is limited and recoverable: separated environments, least privilege, tested backups, and logging that lets you reconstruct what happened.
-
Automate the routine work Dependency monitoring, certificate renewal and backup verification should not rely on someone remembering. Human-dependent routine security fails predictably.
-
Be specific about residual risk Every assessment states what was reviewed, what was not, and what risk remains after the recommended work. Vague reassurance is worse than a clear list.
What you receive
- Security assessment with findings prioritised by exploitability and impact
- Dependency inventory and known-vulnerability report
- Hardening implementation: headers, TLS, permissions, configuration
- Access control review and remediation
- Backup and tested restore procedure
- Monitoring and alerting configuration
- Incident response runbook
- Statement of scope reviewed and residual risk remaining
How this runs
Every engagement follows the same sequence, with a defined output at each stage and nothing proceeding on an assumption that has not been written down. Operate work sits inside that process rather than alongside it.
Common questions
Is this a penetration test?
No. We perform configuration, dependency and application security review, and hardening. A formal penetration test by a specialist firm is a different exercise, and where you need one we will say so rather than approximate it.
Our site was hacked. Can you help?
Yes. The order is containment, then assessment of what was accessed, then clean-up and restoration, then closing the route used. Restoring a backup without finding the entry point usually results in a second compromise.
How often should security work happen?
Dependency and patch management is continuous – it is part of a support arrangement. A fuller review is worth running annually, and after any significant change to the application or its integrations.
Related services
Not sure how exposed you are?
A review gives you a specific, prioritised list rather than a general worry. We will also tell you which items are urgent and which are not.
Or email hello@applystudio.com – we reply within one business day.