A small-business website is ready to launch only when its security requirements match what the site actually does, the important controls have production evidence, and named people can respond when something fails. HTTPS alone is not a security review. A vulnerability scanner alone is not launch approval. A clean test today is not a promise that the site cannot be compromised tomorrow.

The launch decision should account for the website's public pages, administrative accounts, forms, uploads, customer data, third-party scripts, APIs, hosting, domain, deployment path, backups, logs, and incident process. A brochure site with a contact form and an authenticated customer portal do not have the same risk or verification scope.

This guide owns pre-launch website security acceptance. The ongoing website maintenance guide owns patching, backups, monitoring, and incident work after launch. The domain and DNS handoff guide owns registrar and DNS control, while the contractor quote-form checklist owns the complete enquiry-to-CRM workflow.

Define the security launch decision

Write the decision before selecting tools:

Can this approved release expose its intended public functions without known unacceptable risk, and can the business detect, contain, recover from, and learn from a security incident within its agreed responsibilities?

That decision needs four states:

  • Pass: required evidence exists and no launch-blocking exception remains.
  • Pass with recorded limitation: a bounded limitation is accepted by the authorized business owner with compensating controls and a dated remediation plan.
  • Fail: a required control or evidence item is missing.
  • Not applicable: the capability does not exist in this release, with evidence showing why the control does not apply.

Do not use “not applicable” because a check is inconvenient. Do not use “accepted risk” without naming who has authority, what could happen, which temporary protection exists, and when the decision expires.

Security is risk reduction, not certainty. The Canadian Centre for Cyber Security describes its small- and medium-organization controls as a baseline rather than comprehensive protection, and places responsibility for system risk with system owners.

Inventory the real website boundary

Security testing cannot cover a system nobody has defined. Build an inventory of the production release:

| Area | Record | | --- | --- | | Public hosts | Canonical website, redirects, subdomains, APIs, asset hosts, and legacy hosts | | Application | Framework, runtime, server functions, CMS, plugins, themes, and build output | | Data | Form fields, account data, uploaded files, logs, analytics, cookies, and backups | | Accounts | Registrar, DNS, hosting, repository, deployment, CMS, CRM, email, analytics, and vendors | | Integrations | Forms, calendar, CRM, chat, maps, reviews, payments, email, SMS, and webhooks | | Administrative surfaces | Login pages, dashboards, deployment endpoints, preview systems, and support tools | | Release path | Source, review, build, artifact, environment configuration, deployment, and rollback | | Owners | Business owner, technical owner, privacy contact, incident lead, and vendor contacts |

Trace sensitive information from collection to deletion. For each data flow, identify the input, purpose, destination, transport, storage, access, retention, logging, backup, and deletion path. If the team cannot say where a quote request or uploaded file goes, it cannot evaluate who can access it or how to remove it.

Inventory staging and preview systems too. A production site can be carefully controlled while an old preview host exposes the same content, environment values, customer test data, or administrative interface.

Scale verification to the website's risk

OWASP's Application Security Verification Standard provides testable requirements for web application controls. It is a useful basis for choosing coverage, not a badge that should be claimed without completing the relevant verification.

Classify the release:

  • Public information site: public pages, ordinary navigation, and no data collection.
  • Lead-generation site: forms, calendars, chat, call tracking, CRM delivery, or marketing tags.
  • Transactional site: payments, customer-specific records, authenticated actions, or valuable business workflows.
  • Sensitive application: regulated, health, financial, identity, high-value, or safety-related information and operations.

Higher-impact features require more design review, stronger access controls, deeper testing, more detailed logging, and specialist involvement. Do not apply a lightweight marketing-site checklist to an authenticated portal. Conversely, do not add enterprise controls with no connection to the actual threat model merely to make a proposal look sophisticated.

Record the chosen standard version, requirements in scope, exclusions, test method, tester, environment, date, findings, and remediation state. A generic “OWASP compliant” statement does not provide that evidence.

Put business accounts under durable control

The business should retain authority over the accounts that keep the website reachable and recoverable. For every critical account, record:

  • legal or business owner;
  • named administrative users;
  • role and least privilege;
  • multifactor-authentication status;
  • recovery method and recovery owner;
  • backup administrator;
  • billing and renewal responsibility;
  • last access review; and
  • offboarding procedure.

Require multifactor authentication where the provider supports it, especially for registrar, DNS, hosting, repository, deployment, CMS, email, CRM, and password-manager administration. Review recovery paths with the same care as login: a weak support reset can bypass a strong primary factor.

Do not share one administrator password among staff and vendors. Use individual identities where available so access can be attributed and removed. Do not leave a departing developer, agency, or employee as the only person able to deploy, renew the domain, rotate a secret, restore a backup, or remove another user.

Keep secrets out of public and reviewable surfaces

Secrets include API keys, database credentials, deployment tokens, private keys, webhook-signing secrets, email-provider credentials, and privileged session values. They do not belong in browser bundles, public repositories, analytics parameters, screenshots, tickets, documentation examples, or command output.

For every production secret, record:

| Field | Required decision | | --- | --- | | Purpose | Which system and operation requires it | | Storage | Approved secret or environment system | | Access | Workload and people permitted to retrieve it | | Delivery | How it reaches the production process without entering source or build output | | Rotation | Trigger, procedure, and owner | | Revocation | How access is disabled after exposure or offboarding | | Logging | How values are redacted from application and deployment output |

Scan source history and built browser assets, not only current source files. Removing a key from the latest commit does not revoke a value that was already exposed. Rotate a confirmed exposed credential through the provider, investigate its use, and document the containment rather than relying on deletion alone.

Client-side configuration is public by design. If a browser must receive a value, do not treat obscurity, minification, or an environment-variable name as access control.

Verify HTTPS as a complete path

TLS protects traffic in transit when correctly implemented. It does not validate form logic, secure a compromised server, or control what a third-party script reads in the browser.

Test:

  • the preferred HTTPS host returns the intended website;
  • HTTP reaches HTTPS through the approved direct redirect or is otherwise intentionally handled;
  • certificates cover every required production and redirect host;
  • the chain is trusted and the certificate is not near an unmanaged expiry;
  • pages do not load active resources over unencrypted HTTP;
  • APIs reject or safely handle unencrypted requests according to their design;
  • cookies that require confidentiality use appropriate security attributes; and
  • monitoring and renewal ownership are assigned.

Evaluate HTTP Strict Transport Security carefully. HSTS can direct supporting browsers to use HTTPS and prevent bypassing certificate warnings, but an incorrect long-lived policy or unprepared subdomain can make legitimate services inaccessible. Confirm certificate automation, host coverage, subdomain effects, rollback implications, and ownership before increasing duration or requesting preload status.

The canonical, redirects, certificates, DNS, and application host must agree. A green certificate on one hostname does not prove the old host, www variant, API, or third-party callback is correct.

Set browser security policy intentionally

HTTP response headers can reduce specific browser risks, but no copied header set is correct for every website. Inventory page behaviour and external resources before enforcement.

Review as applicable:

  • Content-Security-Policy for allowed scripts, styles, images, frames, connections, and other resources;
  • frame-ancestors in CSP or an appropriate framing policy;
  • X-Content-Type-Options: nosniff;
  • Referrer-Policy;
  • Permissions-Policy for browser capabilities the site does or does not need;
  • HSTS after HTTPS readiness is established;
  • cookie Secure, HttpOnly, and SameSite attributes according to cookie purpose; and
  • cache controls for responses containing sensitive information.

Begin a CSP with a documented inventory. Report-only deployment can help discover violations, but collected reports must have an owner and should not receive unnecessary personal or sensitive data. Move to enforcement only after the required site journeys work with the approved policy.

Do not copy obsolete headers from an old checklist. Do not declare success because an automated score is high. Verify that the policy blocks unintended behaviour without breaking navigation, forms, calendars, chat, payment, accessibility, or consent functions.

Validate every untrusted input on the server

Browser validation improves usability but can be bypassed. Validate requests in the trusted server or provider boundary before the data changes state or reaches another system.

Use both:

  • syntactic validation: the value has the expected structure, type, length, and encoding; and
  • semantic validation: the value is allowed in the business context.

For a contractor form, a date can be well formatted but outside operating hours. A service identifier can be valid text but not one of the services the endpoint accepts. A URL can be syntactically valid but point to a destination the server must never retrieve.

Define maximum request sizes, field lengths, allowed values, normalization, error behaviour, and downstream encoding. Prefer allowlists for bounded categories. Encode untrusted output for the context where it is used rather than treating input validation as the sole protection against injection.

Test missing fields, unexpected fields, oversized values, alternate encodings, repeated requests, stale tokens, malformed JSON, and direct endpoint access without the intended page. Keep customer-safe errors separate from internal diagnostic detail.

Treat forms and APIs as abuseable public endpoints

A public form can be used for spam, automated volume, malicious payloads, notification abuse, or attempts to exhaust paid provider capacity.

Define:

  • server-side validation;
  • request and payload limits;
  • abuse detection appropriate to observed risk;
  • rate controls at a useful boundary;
  • duplicate and retry handling;
  • provider spend or quota alerts;
  • safe error messages;
  • recoverable delivery; and
  • a fallback contact path.

Avoid controls that silently block legitimate customers without review or recovery. CAPTCHA, reputation services, and managed bot controls create accessibility, privacy, availability, and vendor dependencies of their own. Test them with keyboard use, assistive technology where relevant, privacy states, slow networks, and provider failure.

The website accessibility checklist covers the wider accessibility target. Security controls do not excuse an unusable customer path.

Remove file uploads unless the business needs them

File upload expands the attack and data-handling surface. Do not add it to a quote form simply because a form builder offers the field.

When the business genuinely needs uploads, define:

  • permitted business purpose;
  • authorized uploader;
  • allowed extensions from a narrow allowlist;
  • validation of actual content rather than trust in the supplied content type;
  • file and request size limits;
  • application-generated storage names;
  • storage outside executable or directly served paths where practical;
  • malware or content analysis appropriate to risk;
  • access authorization;
  • retention and deletion;
  • staff review procedure; and
  • customer-safe failure and support path.

Do not use the customer-supplied filename as a storage path. Do not make every upload publicly retrievable at a predictable URL. Do not copy uploaded documents into analytics, notification emails, logs, and CRM notes without an approved need and handling design.

Test double extensions, misleading content types, oversized files, empty files, duplicate names, malformed content, interrupted uploads, unauthorized retrieval, and deletion. OWASP emphasizes defence in depth because no single file check is sufficient.

Inventory third-party code and connected services

Third-party JavaScript executes in the visitor's browser and can affect the page, read available browser data, or change independently of the site's release. Tag managers can make production changes outside the repository deployment path.

For each script, embed, iframe, pixel, or SDK, record:

  • business purpose;
  • vendor and account owner;
  • pages where it loads;
  • data available to it;
  • destinations it contacts;
  • consent state required;
  • version or delivery method;
  • integrity or isolation controls where supported;
  • permissions and tag-manager publishers;
  • failure behaviour;
  • removal procedure; and
  • last review date.

Remove scripts with no current approved purpose. Restrict tag-manager publishing access and require review evidence for production changes. Validate what the browser actually requests and sends under each consent state; a configuration screenshot does not prove runtime behaviour.

Treat calendars, CRM endpoints, chat, email, and payment providers as security boundaries too. Use current provider authentication or webhook-verification methods, limit privileges, protect callback endpoints, and make repeated or out-of-order processing safe.

Build and deploy a known release

The production website should be traceable to reviewed source and a repeatable release process.

Record:

  • source revision;
  • dependency lockfile or equivalent resolved inventory;
  • approved build environment;
  • build and test results;
  • artifact identity where the platform supports it;
  • production configuration source;
  • deployer identity;
  • deployment time;
  • database or content migration step;
  • rollback conditions; and
  • post-deployment verification.

NIST's Secure Software Development Framework organizes practices around preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. Adapt those practices to the project's size without discarding traceability.

Review direct and transitive dependencies, remove unused packages and plugins, and identify unsupported software. Use authoritative vendor advisories and credible vulnerability data. CISA's Known Exploited Vulnerabilities catalogue can inform prioritization when an inventoried component is affected by a vulnerability with evidence of exploitation; it is not a complete list of everything that can be exploited.

Do not deploy from an unreviewed workstation state or include unrelated changes in an emergency release. A fast patch still needs an identified target, controlled change, verification, and rollback decision.

Make errors useful without exposing the system

Public errors should help the visitor recover without revealing stack traces, internal paths, SQL details, environment values, tokens, provider payloads, or private customer data.

Define customer-safe behaviour for:

  • missing pages;
  • invalid form input;
  • authentication failure;
  • authorization failure;
  • dependency timeout;
  • provider rejection;
  • upload failure;
  • rate control;
  • server error; and
  • planned maintenance.

Return the correct HTTP status. Do not serve the homepage with 200 for every unknown URL. Do not expose different authentication messages that unnecessarily reveal whether a particular account exists.

Production should not depend on debug mode. Test error handling after the production build is deployed, because development and production frameworks often expose different details.

Log security evidence without logging secrets

Useful logs support detection, investigation, recovery, and accountability. More logging is not automatically safer.

Define events worth recording, such as:

  • administrative sign-in and recovery changes;
  • permission and account changes;
  • deployment and configuration changes;
  • repeated validation or authentication failures;
  • rate-control actions;
  • webhook verification failures;
  • upload processing results;
  • dependency or provider failures;
  • secret rotation and revocation events; and
  • security-control configuration changes.

Record consistent timestamps, event type, safe subject or request identifiers, outcome, component, and correlation values. Protect log integrity and access. Define retention and alert ownership.

Do not log passwords, session tokens, API keys, encryption keys, full payment data, unnecessary contact details, free-text enquiries, or uploaded content. Redact at the source where practical. A secret copied into a centralized log can have a wider audience and longer retention than the application that received it.

Run a test event and prove that the intended alert reaches an accountable person. A configured alert with no recipient or an unmonitored inbox is not a response control.

Prove that recovery works

Identify what the website needs to recover:

  • source and deployable release;
  • content and databases;
  • uploaded assets where applicable;
  • environment and infrastructure configuration;
  • DNS and certificate dependencies;
  • provider configuration records;
  • account-recovery paths; and
  • instructions required to restore service safely.

Define the business's tolerable data loss and recovery delay before choosing backup frequency or architecture. Do not invent a recovery promise after an outage.

Test restoration to a controlled destination. Record the backup identifier, restore point, components restored, authorization, elapsed time as test evidence rather than a public guarantee, missing dependencies, integrity checks, and corrective work. Confirm that a restored system does not accidentally send customer messages, process payments, publish a staging host, or connect to production integrations.

A successful backup job proves that a copy process reported success. A restoration test provides stronger evidence that the required system can be reconstructed.

Prepare an incident response path

The Canadian Centre for Cyber Security includes incident response among its baseline controls for smaller organizations. A website launch should identify what happens when a suspected compromise, exposure, defacement, malicious redirect, account takeover, or data-handling incident is reported.

Record:

  • reporting channel;
  • primary and alternate incident leads;
  • hosting, registrar, DNS, repository, and vendor escalation contacts;
  • authority to disable a feature, revoke a credential, block traffic, or take the site offline;
  • evidence-preservation procedure;
  • communication and privacy-review owners;
  • recovery and verification steps;
  • criteria for specialist or legal involvement; and
  • post-incident review owner.

Do not put the only response instructions inside the potentially compromised system. Keep an approved offline or separately controlled copy with current contact information.

This checklist is not breach-notification or legal advice. Applicable reporting, notification, evidence, privacy, insurance, contractual, and regulatory duties depend on the organization, data, jurisdiction, sector, and incident. Assign qualified reviewers before an incident forces the decision.

Run a production security acceptance matrix

The following Nexxen matrix is an original operational framework. It is not a penetration-test report, certification, or claim about an unverified client.

| Control area | Production evidence | Blocking condition | | --- | --- | --- | | Scope | Hosts, functions, data, accounts, integrations, and owners inventoried | Unknown public or administrative surface | | Accounts | Individual access, MFA state, recovery, and offboarding verified | Business lacks durable control of a critical account | | Secrets | Server-side storage, access, redaction, and rotation documented | Confirmed exposed credential remains valid | | HTTPS | Required hosts, redirects, certificates, mixed content, and renewal tested | Sensitive or canonical journey uses unsafe transport | | Browser policy | Applicable headers and cookies tested against real journeys | Policy absent without decision or breaks required controls | | Inputs | Server validation, output handling, limits, and direct endpoint tests | Untrusted input reaches a sensitive operation unchecked | | Uploads | Purpose, allowlist, content checks, storage, access, and deletion verified | Unrestricted or publicly exposed upload path | | Third parties | Scripts, data, permissions, consent, failure, and removal inventoried | Unknown script or provider receives uncontrolled data | | Release | Reviewed revision, locked dependencies, build, deployment, and rollback recorded | Production cannot be tied to an approved release | | Errors and logs | Safe errors, useful events, redaction, access, alerts, and retention tested | Secrets or unnecessary personal data exposed | | Recovery | Required assets inventoried and controlled restoration completed | No usable recovery path for a critical system | | Incident response | Leads, authority, contacts, evidence, containment, and recovery assigned | Nobody can act on a credible security incident |

For every exception, record the affected asset, scenario, likelihood and impact assessment owner, existing protection, temporary control, authorized decision-maker, remediation, due date, retest, and closure evidence.

Recheck the final public deployment, not only a local or staging build. Validate representative pages, forms, APIs, uploads, administrative surfaces, and error paths. Automated tools can find specific classes of issue; manual review is still needed for business logic, access decisions, sensitive data flows, recovery, and third-party boundaries.

Hand security into maintenance

Launch acceptance expires as software, accounts, vendors, threats, and business processes change. Hand the verified inventory and open risks into an ongoing owner.

The handoff should include:

  • production host and asset inventory;
  • account and access register;
  • security requirements and test evidence;
  • dependency and release inventory;
  • secret rotation and revocation procedures;
  • third-party script and integration register;
  • log, alert, and retention configuration;
  • backup and restoration evidence;
  • incident contacts and authority;
  • accepted exceptions and due dates; and
  • review triggers.

Trigger a review when the site adds authentication, payments, uploads, personal information, a new form or integration, a tag-manager vendor, administrative users, a platform migration, or a material dependency change. Recheck after a confirmed credential exposure, vulnerability notice, security incident, or unexplained production behaviour.

The correct launch statement is bounded: the defined release passed the defined checks on the recorded date, with the listed limitations and owners. It is not “the website is secure forever.”

For Canadian small businesses that need reviewable implementation, production acceptance, controlled integrations, and maintained website operations, Nexxen's website development service is the commercial owner for this resource.