# Website Security Checklist for a Business Launch

> Review access control, dependencies, uploads, secrets and recovery before launching a business website, with checks tied to real user journeys.

- URL: https://weaveward.com/blog/website-security-checklist
- Published: 2025-06-25
- Updated: 2026-10-12
- Category: Security & Cloud
- Tags: website-security, access-control, maintenance
- Author: Weaveward Team

A business website's security depends on what it actually does. A brochure site, an owner CMS and a customer portal have different failure paths. Start a security checklist by identifying stored information, privileged actions and external services, then test those boundaries through the application rather than treating HTTPS as the whole review.

For a hypothetical company profile, the most consequential paths may be editor access, enquiry storage and uploaded images. An attacker should not be able to read private leads or publish an article merely by discovering an API address.

## Draw the access boundaries

List public pages, signed-in owner functions and server-only operations. Include file URLs, exports and background jobs. A private button in the interface does not make its underlying endpoint private.

[OWASP's authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) distinguishes identity from permission. For your own checklist, specify who can read, create, update and delete each record. Test an anonymous request and a user attempting to access another user's identifier where accounts exist.

## Keep credentials out of delivery assets

Separate public build configuration from server secrets. Review environment examples, screenshots, logs and source archives before sharing them. A variable's name does not provide protection if its value is embedded in browser JavaScript.

Use independent credentials for the database, email provider and session signing. Document how to rotate them and who controls the accounts. Avoid passing sensitive values as shell arguments that may remain in terminal history or process listings.

## Review input and uploaded files

Set explicit request and file-size limits. Validate expected fields on the server, including status values and record versions. Encode or sanitize content for the context in which it appears; validating a title does not automatically make arbitrary HTML safe.

Use [OWASP's file upload guidance](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) as a reference when uploads exist. Decide which formats are necessary, assign server-generated filenames and define when an upload becomes publicly accessible. A draft article's media can contain private information even if the article itself is hidden.

## Make sessions and logout meaningful

Check cookie settings, expiry and server-side revocation. Verify that an expired login cannot continue making changes through a stale tab. Owner sign-out should end the actual session rather than only removing a visual indicator.

Rate-limit login attempts and sensitive public forms using a storage mechanism appropriate to the hosting runtime. An in-memory limit disappears when a process restarts and may split across multiple instances. Test the behaviour expected from your actual deployment.

## Prepare for dependencies and failure

Maintain a dependency update process with a named owner and a staging check. Review what a changed package can affect, especially rendering, authentication and the deployment adapter. Pin or constrain critical infrastructure versions when compatibility requires it, while documenting how the constraint will be revisited.

Back up the records the business cannot reconstruct. Perform a restore into an isolated environment and check access permissions afterward. A backup schedule without evidence of restoration leaves a major operational uncertainty.

## Use a release evidence sheet

Record the tested action, expected response, result and remaining limitation. Useful checks include anonymous editor access, rejected unsafe uploads, cross-origin writes, draft visibility, secret scanning and a failed dependency service. Resolve material failures before collecting genuine customer information.

This checklist does not replace a risk review or penetration test for a sensitive portal. It gives a small business website a concrete starting point that can grow with its functions. Read the [secure contact form guide](/blog/secure-contact-form-lead-capture) and [backup restore plan](/blog/database-backup-restore-plan), or discuss the release with our [web application team](/services/web-apps).