Website security in 2026: a practical checklist beyond the login screen
Use the OWASP Top 10:2025 as a starting point for reviewing permissions, dependencies, forms and recovery before your next release.
A login screen is one part of website security. The more useful question is what the application permits after a request reaches the server. Can one customer access another customer's record? Can an editor change an administrator's settings? Does a failed integration expose private details?
The OWASP Top 10:2025 gives development teams an updated awareness framework. Broken access control remains first on the list; the release also includes software supply chain failures and mishandling of exceptional conditions. These are helpful prompts for a review, rather than a certificate that a website is secure.
The checklist below is Moonera's practical planning guidance. It translates that starting point into questions a business owner can discuss with a development or security team.
1. Review permissions behind every sensitive action
Write down the important roles in your product and what each role may read or change. Include ownership: a customer may have permission to view an invoice, but only an invoice belonging to their account.
OWASP's Authorization Cheat Sheet recommends least privilege, denial by default and permission validation on every request. In practice, the server should enforce these rules even when a request bypasses the normal interface.
Ask for evidence from authorised tests using separate accounts. Useful cases include a lower-privilege user attempting an administrative action and one customer's identifier being used from another customer's session. A hidden button alone does not establish an access boundary.
2. Include enquiry forms and the admin inbox
A form's trust boundary continues into the places where its contents appear: admin tables, email templates, exports and internal tools. An unexpected value should remain data throughout that journey.
For a project brief, ask how field types and lengths are enforced on the server, how database queries are parameterised, and how submitted text is escaped in each output context. Cookie-authenticated changes also need a considered CSRF defence. These controls address different problems; a single “sanitize input” checkbox does not describe the whole design.
- Bound request sizes and individual field lengths.
- Define which values the application actually accepts.
- Review output handling in the admin panel as well as the public page.
- Keep database credentials and application secrets outside public assets.
- Test unexpected and repeated submissions in an authorised environment.
3. Know what you deploy and who can update it
A website includes application code, packages, plugins, deployment tools and hosting configuration. Make an inventory that someone is responsible for maintaining. Record where updates come from and how the team checks a change before release.
For a small business site, the immediate task may be identifying abandoned plugins or removing unused extensions. For a custom application, it may involve reviewing dependency changes, protecting deployment credentials and maintaining a repeatable build. Prioritise the components that can affect sensitive records or privileged access.
4. Treat admin access as an operating process
List every administrator and service account. Remove access that is no longer needed, separate everyday editorial access from hosting administration, and use strong authentication suitable for the system.
Recovery matters too. Establish who can restore an administrator's access, what evidence they need and how the event is recorded. A recovery process that grants broad access through an unverified request can undermine the normal login controls.
5. Plan failure, monitoring and recovery
Before launch, walk through a failed database connection, a notification timeout and a duplicate form submission. Define what the user sees, what the team records and which actions are safe to retry.
Backups should have an owner, a retention policy and a restoration exercise. For abuse protection, agree hosting or edge request limits alongside application controls. Application throttling is useful, but distributed traffic and exhausted server connections also require infrastructure-level planning.
What should a security review deliver?
Ask for an agreed scope, evidence for findings, a prioritised remediation plan and a way to verify fixes. Identify the systems and accounts that may be tested before assessment begins. This article is a planning aid, not evidence that any particular website has passed a security assessment.
If your project also uses an AI assistant, read our guide to AI agent permissions and prompt injection. For an existing website or API, discuss an authorised security assessment with Moonera.
Sources and further reading
Research checked on 30 October 2026. The checklist and examples are Moonera's editorial recommendations, not a claim of OWASP certification.
