A website can look finished while its security is still unfinished.
The pages load. The checkout works. The contact form sends a message. Behind that experience sit DNS records, hosting accounts, application code, third-party components and recovery systems, and each one carries assumptions about who can connect, what they can access and how the business would recover if something went wrong.
For founders and agencies, the useful question is how those controls behave under pressure. Can traffic bypass the protective proxy? Can someone reach an abandoned subdomain? Would a compromised hosting account also expose every backup?
Here are eight areas to settle before those questions become urgent.
1. Protect the origin behind your public website
A reverse proxy such as Cloudflare routes web traffic through an intermediary that provides security controls before requests reach your origin server. With eligible DNS records proxied, visitors receive Cloudflare addresses rather than the origin address in those DNS responses.
That reduces direct exposure, but it does not make the origin invisible. The underlying address can still become known through historical records, other services or configuration mistakes, and a server that accepts direct web connections may allow traffic to bypass the proxy.
Where your hosting architecture supports it, restrict origin web access to the intended proxy and authorised management paths. Account for legitimate integrations, health checks and certificate renewal before changing firewall rules.
The control to verify is easy to state: does direct access to the origin bypass the protections applied at the edge?
Source: Cloudflare: Protect your origin server.
2. Configure edge protection before an incident
A proxy account is the beginning of a configuration task, not the end of one. Review the firewall, bot controls and rate limits available on your plan, then check that important application flows still work.
Login, password reset, checkout and API endpoints have different traffic patterns, and browser challenges can disrupt legitimate automated clients. Rules should reflect how each route is actually used.
Document what you would change during a traffic spike and who can make that decision. Cloudflare’s Under Attack mode adds checks intended to help mitigate application-layer DDoS attacks; enabling the proxy early does not remove the possible need for changes during an incident.
Your deployment plan should cover normal operation, escalation and recovery.
Source: Cloudflare: Under Attack mode.
3. Design backups around a compromised account
Ask your hosting provider what its backups contain, how long they are retained and how you would restore them. Then ask the harder question: could the same compromised credentials delete both the live website and its recovery copies?
Maintain an appropriately protected, separate backup. Depending on the application, recovery may require database contents, uploaded files, source code, configuration and securely managed secrets. Protect backup access with strong authentication and limit who can modify or delete recovery data.
Test a restoration into a separate environment. Record what was recovered, what was missing and how long it took.
The business needs answers to two questions: how much recent data could be lost, and how long could the service remain unavailable?
Source: NCSC: Data security.
4. Keep an authoritative DNS inventory
DNS changes can affect your website, email, verification records and connected services. Keep a current export or versioned configuration, with a clear owner for each important record.
Historical DNS services may help an investigation, but their records can be incomplete or stale. Treat them as supporting evidence when reconstructing a configuration, not as the source of truth.
Include subdomains in routine reviews. A staging site, an old customer portal or an abandoned integration can stay reachable long after the main website has moved on. Confirm ownership and purpose before removing records.
Keep recovery instructions and registrar access available to authorised staff in case the primary hosting service becomes unavailable.
Source: NCSC: Prepare your technical recovery capability.
5. Give transactional email its own delivery configuration
Password resets, order confirmations and contact-form notifications deserve a managed sending setup.
A reputable transactional email provider, used through its API or authenticated SMTP service, can help with delivery monitoring and bounce handling. Deliverability still depends on authentication, reputation, recipient behaviour and message quality.
Configure SPF and DKIM for the services authorised to send on your behalf, and introduce DMARC with appropriate monitoring and alignment. Check the messages your application actually sends, including their visible sender addresses.
Using PHP to initiate an email does not, by itself, determine whether that message is accepted. Verify the complete sending path and monitor failures.
Source: Google: Email sender guidelines.
6. Use web archives as a reconstruction aid
The Wayback Machine can sometimes help recover public wording, images or page layouts after a loss. Its own guidance explains that archived captures may be incomplete.
An archive cannot be relied on to recover your application database, private customer records, server configuration or working backend, and some public pages and assets may be absent too.
Use available captures to assist reconstruction when you need to. Make tested backups the basis of your recovery plan.
Source: Internet Archive: Using the Wayback Machine.
7. Maintain the complete software stack
Create an inventory that includes the application, runtime, framework, plugins, themes and supporting services. Establish who reviews security updates and how urgent fixes reach production.
For WordPress sites, review core, themes and plugins together. Use supported components, remove software you don’t need and check that the remaining dependencies are actively maintained.
A useful update process combines timely patching with backups and proportionate compatibility checks. Critical exposure needs a response path that can move faster than a routine maintenance appointment.
Keep records of what changed, so the team can investigate a problem or reverse a failed deployment.
Sources: WordPress: Security and WordPress: Plugin and theme auto-updates.
8. Apply the same scrutiny to purchased and AI-generated code
Install plugins and themes from reputable sources. Unofficial or modified packages introduce uncertainty about both their contents and their update path.
Custom code needs its own maintenance plan. Asking an AI assistant to build a replacement plugin does not establish that the result is secure.
Review how it handles authentication, permissions, user input, database access and sensitive information. Test the relevant behaviour in a separate environment before deployment, and assign responsibility for subsequent updates.
AI-assisted review can contribute to that work. Validate the security properties the component needs to enforce with reproducible tests.
Source: WordPress: Securely developing plugins and themes.
Put your security assumptions to the test
Configuration reviews establish what should happen. An adversarial assessment examines whether those expectations hold within an agreed scope.
For a website or SaaS application, that could mean testing origin exposure, authentication, permissions, file access and sensitive workflows. Evidence-backed findings then give developers specific changes to make, and checks to repeat once they are fixed.
Good security work connects the control, the test, the observed result and the verified fix.