Website Security Checklist for Sri Lankan Businesses

Website security is a continuing risk-management process. A small marketing site and a customer portal do not need identical controls, but both need clear ownership, supported software, restricted access, and a recoverable operating plan. Use this checklist as a starting point and increase assurance for payments, health, finance, identity, or other sensitive workflows.

The OWASP Top 10:2025 is a current awareness reference for major web-application risks, including broken access control, security misconfiguration, supply-chain failures, cryptographic failures, and injection. A checklist does not replace threat modelling, code review, or professional testing, but it prevents common omissions.

Own every critical account

Maintain a register for the domain, DNS, hosting, source repository, deployment, content system, email, analytics, payment providers, and third-party integrations. Use company-controlled accounts and record a business owner and technical owner.

Require strong unique passwords and multi-factor authentication where available. Grant the minimum role needed, review access quarterly, and remove it immediately when employment or a supplier relationship ends. Avoid shared administrator accounts; individual identities create accountability.

Store recovery codes and signing or deployment credentials in an approved secure location. Test account recovery before an emergency.

Keep software and the supply chain current

Inventory frameworks, plugins, packages, runtime versions, operating systems, containers, external scripts, and services. Subscribe to security advisories and define how quickly critical issues must be reviewed. Remove unused packages and integrations; every dependency adds maintenance and trust.

Apply changes through a tested release process. Lock dependency versions appropriately, review unexpected package changes, protect the build pipeline, and keep production secrets out of source control. If a component is no longer supported, plan its replacement rather than accepting indefinite exposure.

Enforce access on the server

Every protected action and record must be authorised on the server. Hiding a button is not access control. Test ordinary users attempting administrator actions, users accessing another customer’s identifiers, and unauthenticated requests to private endpoints.

Validate input by expected type, length, format, and business rule. Use parameterised database access and safe output encoding. Restrict file types, size, storage location, and retrieval permissions for uploads. Treat data from browsers, webhooks, partner APIs, and AI tools as untrusted.

For a new project, write these requirements into the product requirements document and acceptance tests.

Protect transport, sessions, and browser behaviour

Use HTTPS on every page and redirect HTTP consistently. Configure certificates to renew and alert before failure. Mark cookies with appropriate Secure, HttpOnly, and SameSite attributes. Regenerate sessions after authentication and expire them according to risk.

Set security headers deliberately, including a practical Content Security Policy where the application can support it. Restrict framing, referrer information, and browser capabilities according to need. Do not copy a header bundle without testing its effect on payments, maps, advertising, or other approved integrations.

Minimise and protect data

Collect only information required for a defined purpose. Document where it travels, who can access it, how long it is retained, and how deletion or correction requests are handled. Encrypt sensitive data at appropriate boundaries and manage keys separately.

Do not send confidential form contents to broad mailing lists or log secrets, tokens, passwords, or full payment data. Use a payment provider’s supported flow instead of handling card details unnecessarily. The e-commerce payment planning guide covers safer integration decisions.

Prepare backups and incident response

Define backup frequency from acceptable data loss, not habit. Separate backups from the production account where possible, encrypt them, monitor completion, and test a full restoration. Record how long restoration actually takes.

Create an incident contact list and a short plan for compromised accounts, malicious changes, leaked credentials, ransomware, payment issues, and unavailable services. Preserve evidence, contain damage, rotate affected secrets, communicate responsibly, and record corrective actions. Confirm legal and contractual notification duties with qualified advisers for the specific incident.

Monitor useful signals

Alert on repeated login failures, privilege changes, unusual exports, unexpected deployment, disabled security settings, malware indicators, error spikes, and certificate or backup failure. Centralise important logs and protect them from ordinary application accounts.

Scan dependencies and public endpoints, but do not treat an automated scan as proof of security. High-risk applications need manual review and testing by appropriately authorised professionals. Never test a third party’s system without permission.

Review the surrounding website

Security controls must not make the service unusable. Test account recovery, form errors, session expiry, permission denial, and support routes with real users. Maintain the site using the small-business launch checklist and choose infrastructure with clear backup and support responsibility using the hosting guide.

Assign monthly update reviews, quarterly access checks, regular recovery exercises, and an annual risk assessment. A website development engagement should identify who operates each control after handover. To scope a security-focused rebuild or remediation, share the architecture and priority risks through Get Started.