Website security checklist for WordPress, stores and web apps
A website security checklist should cover the information and actions the business actually needs to protect. WordPress, online stores and custom web applications have different operating details, but all need deliberate access, updates, input handling and recovery. Use this guide to organise practical responsibilities and acceptance checks. A security plugin or hidden URL can be one part of a system; neither replaces a clear protection model.
Key takeaways
- Define which accounts, records, files and actions need protection.
- Enforce access on the server and keep secrets outside public browser code.
- Maintain updates, recovery and a response process as ongoing responsibilities.
Inventory what must be protected and who owns it
List privileged accounts, customer records, private files, payment-related integrations and the business services needed to operate the site. Identify who controls the domain, hosting, repository and external accounts. An unfamiliar account left with a previous supplier can become an operational problem even when the public pages appear healthy.
Describe the consequence of losing access or exposing each kind of information. This helps prioritise work sensibly. A public article image does not need the same controls as a client's private document. Keep the inventory proportionate and assign an owner who can make decisions about retention, access and recovery. The goal is a clear model of what the website handles and the boundaries it must enforce.
- Name the sensitive records, files and privileged operations.
- Confirm business ownership and recovery access for essential services.
Review permissions beyond the login screen
Specify the actions each role can perform and which records it may access. Test those rules on the server, including direct requests for private files or records. A hidden button or a difficult-to-guess link does not establish permission. OWASP's authorization guidance provides a reference for enforcing access decisions where resources are actually requested.
Review administrative access when staff, contractors or providers change. Give people the access their work requires and remove it when that responsibility ends. Keep shared credentials out of routine communication where an individual account or controlled access mechanism is available. Check account recovery as well: a carefully restricted interface is undermined if its recovery route is owned by an abandoned inbox.
| Area | Practical requirement | Acceptance question |
|---|---|---|
| Accounts | Appropriate permissions and recovery | Can an unauthorised account perform this action? |
| Private files | Protected upload and download routes | Does a direct URL bypass the account boundary? |
| Secrets | Controlled server-side configuration | Are credentials absent from public assets and routine logs? |
| Updates | Known dependencies and a safe release process | Can a significant change be checked and restored? |
| Recovery | Protected backups and assigned response | Who can restore the required data and service? |
- Test private-record access using separate accounts and direct requests.
- Review privileged access and recovery ownership when responsibilities change.
Validate forms, uploads and connected services
Review what the application accepts from public forms, account screens and external systems. Define expected fields and file types, apply server-side validation and give legitimate users a useful error state. File handling deserves its own review: an upload's claimed type is not sufficient evidence of its contents, and private downloads need their own access checks. OWASP's upload guidance describes implementation considerations in more detail.
For connected services, follow the provider's documented authentication or request-verification method. Limit credentials to the required capability and plan how they are renewed or revoked. Keep debugging useful without recording unnecessary personal information or secret tokens. When a connection fails, the business needs a visible, controlled recovery path rather than a workaround that temporarily removes the protection.
- Validate the data the server uses, not only the visible form fields.
- Check uploads, downloads and integration requests as distinct entry points.
Keep software and deployment under control
Maintain an inventory of the software and extensions in use. Remove components that are no longer needed after checking their role, and obtain updates from the appropriate official source. For WordPress, the hardening handbook is a useful starting point for platform-specific care. Custom applications need equivalent attention to their dependencies and deployment configuration.
Use a controlled release process with a restorable copy and checks for the core user journey. Keep development tools and administrative files out of unnecessary public access. Restrict write access according to the hosting and deployment setup rather than applying a copied permission command without understanding it. Record changes so a later incident can be investigated against what actually happened, not only the last person to remember editing the site.
- Track versions, dependencies and the purpose of installed extensions.
- Protect configuration and verify significant releases before accepting them.
Prepare recovery and a response before an incident
Define the files, data and configuration needed to restore the service, and protect the backup copies. Perform a controlled restore where practical so missing dependencies are found before an emergency. Agree who receives a meaningful alert and who has authority to investigate, revoke a credential or restore a release. An alert without an owner is an incomplete control.
Keep the response process readable. Record the affected service, the observations, the actions taken and the checks needed before normal operation resumes. Avoid making strong claims about security from a single scan or plugin result. Review the protection model when new account types, uploads or integrations are introduced. Security remains useful when it is connected to the site's actual workflows and maintained as those workflows change.
- Test recovery access without modifying the current live data.
- Assign incident ownership and review controls when scope changes.
Sources and further reading
Primary documentation for the platform-specific details discussed in this article. The planning examples above are illustrative requirements, rather than client case studies.
Need the access and recovery parts reviewed properly?
Tell me what the website stores, who uses it and which areas must stay private. I can help scope the implementation checks and ongoing responsibilities around those boundaries.
Discuss a projectFrequently asked questions
Practical answers to help you plan the next step.
WordPress can be secure when it is built and maintained properly. Problems usually come from weak passwords, abandoned plugins, poor hosting and no update process.
It depends on how often the site changes. Stores and active portals may need daily or more frequent backups; simpler sites may need less.
Yes, but it is better planned from the start. Access, hosting, backups, updates and monitoring should be part of the build plan.
