Cayvora Secure Website Launch Checklist

Launching a website without a rigorous security audit is like opening a bank vault with the door unlocked. At Cayvora Security, our incident response data reveals a striking statistic: 80% of post-production security incidents could have been prevented by a systematic pre-launch security checklist. This guide is the definitive resource for CTOs, DevSecOps teams, and IT managers in Morocco and beyond who refuse to leave security to chance.

A secure launch is not a luxury — it is the single most cost-effective investment in your digital infrastructure. Fixing a vulnerability in production costs 30x more than catching it before deployment.

---

1. Domain & DNS Security

Your domain name is your digital identity. Compromising it means redirecting your entire customer base to an attacker-controlled server. DNS security is the foundation upon which all other protections are built.

1.1 WHOIS Privacy & Domain Lock

• Enable WHOIS Privacy Protection: Prevent attackers from harvesting registrant contact details (name, email, phone) for targeted spear-phishing campaigns. All major registrars offer this for free or at minimal cost.
• Activate Registrar Lock (clientTransferProhibited): This prevents unauthorized domain transfers. Without this flag, an attacker who compromises your registrar account can silently transfer your domain to their own account.
• Enable DNSSEC (Domain Name System Security Extensions): DNSSEC cryptographically signs your DNS records, preventing DNS cache poisoning attacks where an attacker injects false DNS responses to redirect traffic.

1.2 Email Authentication: SPF, DKIM & DMARC

Email spoofing is the primary vector for phishing attacks. Implementing the email authentication triad ensures that only authorized servers can send emails on behalf of your domain.

• SPF (Sender Policy Framework): Publish a DNS TXT record listing the IP addresses and services authorized to send email for your domain. End with -all (hard fail) to reject unauthorized senders.
• DKIM (DomainKeys Identified Mail): Configure your mail server to cryptographically sign outgoing emails. The recipient server verifies the signature against a public key published in your DNS.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Set a DMARC policy (p=reject) that instructs receiving servers to reject emails that fail both SPF and DKIM checks. Configure aggregate reporting (rua=) to monitor spoofing attempts.

; Example DNS Records for Maximum Email Security
; SPF Record
@ IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

; DMARC Record
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

; CAA Record (restrict certificate issuance)
@ IN CAA 0 issue "letsencrypt.org"
@ IN CAA 0 issuewild ";"

1.3 CAA Records (Certificate Authority Authorization)

• Restrict Certificate Issuance: Publish CAA DNS records to specify exactly which Certificate Authorities (e.g., Let's Encrypt, DigiCert) are permitted to issue TLS certificates for your domain. This prevents an attacker from obtaining a fraudulent certificate from another CA.
• Block Wildcard Certificates: If you don't use wildcards, explicitly deny them with issuewild ";".

1.4 CDN Configuration & DDoS Protection

• Deploy a CDN with WAF: Services like Cloudflare, AWS CloudFront, or Akamai provide a global edge network that absorbs DDoS attacks before they reach your origin server. Ensure the WAF ruleset is tuned to your application's profile.
• Hide Your Origin IP: Never expose your origin server's real IP address. All DNS A records should point to the CDN's edge IPs. Use allowlisting on your origin firewall to accept connections only from the CDN's IP ranges.
• Enable Rate Limiting: Configure rate limiting at the CDN level to prevent brute-force attacks on login pages and API endpoints.

---

2. Encryption Standards & TLS Configuration

Encryption in transit is non-negotiable. Every byte of data exchanged between your users and your servers must be encrypted with modern, audited protocols. There are zero excuses in 2026 for running anything less than TLS 1.2.

2.1 TLS 1.2+ Enforcement

• Disable TLS 1.0 and TLS 1.1: These legacy protocols contain critical vulnerabilities (BEAST, POODLE, CRIME). All modern browsers dropped support for them. Your server configuration must explicitly disable them.
• Prefer TLS 1.3: TLS 1.3 offers a faster handshake (1-RTT vs. 2-RTT), stronger cipher suites by default, and eliminates entire classes of attacks like renegotiation attacks. Prioritize it in your cipher order.
• Strong Cipher Suites Only: Use AEAD ciphers (AES-256-GCM, ChaCha20-Poly1305). Remove legacy ciphers like RC4, 3DES, and CBC-mode ciphers from your configuration.

# Nginx TLS Hardened Configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;

2.2 HSTS (HTTP Strict Transport Security)

• Deploy HSTS with a Long Max-Age: Set Strict-Transport-Security: max-age=63072000; includeSubDomains; preload to force browsers to use HTTPS for 2 years. Include subdomains to prevent subdomain takeover attacks over HTTP.
• Submit to the HSTS Preload List: Register your domain on hstspreload.org so that all major browsers enforce HTTPS from the very first connection, even before visiting your site.

2.3 SSL Labs Grade A+ Target

• Test with SSL Labs: Run your domain through Qualys SSL Labs and aim for a Grade A+ score. Anything below Grade A indicates a configuration weakness that attackers can exploit.
• Certificate Transparency Monitoring: Subscribe to CT log monitoring services to receive alerts if unauthorized certificates are issued for your domain.

---

3. Security Headers & Browser Protections

Security headers are your second line of defense after TLS. They instruct the browser to enforce strict security policies that mitigate XSS, clickjacking, and data injection attacks.

• Content-Security-Policy (CSP): Define a strict allowlist of content sources. Block inline scripts ('unsafe-inline') in production. Use nonces or hashes for necessary inline scripts.
• X-Frame-Options: DENY: Prevent clickjacking by blocking your site from being embedded in iframes.
• X-Content-Type-Options: nosniff: Prevent MIME-type sniffing attacks.
• Referrer-Policy: strict-origin-when-cross-origin: Limit the information leaked in the Referer header to external sites.
• Permissions-Policy: Explicitly deny access to browser features you don't use (camera, microphone, geolocation, payment API).

---

4. Moroccan Regulatory Compliance

Operating a website or e-commerce platform in Morocco carries specific legal obligations that go beyond technical hardening. Non-compliance can result in severe financial penalties, criminal prosecution, and irreversible reputational damage.

4.1 CNDP Compliance (Loi 09-08)

The Commission Nationale de contrôle de la protection des Données à caractère Personnel (CNDP) enforces Morocco's data protection law (Loi 09-08). Before launch, you must:

• File a CNDP Declaration: Submit a formal notification to the CNDP describing the personal data you collect, the purpose of collection, retention periods, and third-party sharing practices.
• Obtain Explicit Consent: Implement clear, affirmative consent mechanisms for data collection. Pre-checked checkboxes are illegal under Moroccan law.
• Appoint a Data Protection Officer (DPO): Designate a responsible person for data protection compliance within your organization.
• Implement Data Subject Rights: Provide mechanisms for users to access, rectify, and delete their personal data.

4.2 Moroccan E-Commerce Law (Loi 31-08)

• Mandatory Legal Information: Display complete legal notices (mentions légales), including company registration, ICE number, tax identification, and physical address.
• Consumer Protection Disclosures: Clearly display pricing (inclusive of all taxes), delivery terms, return policies (14-day withdrawal right), and payment security guarantees.
• Electronic Contract Compliance: Ensure your checkout process follows the two-click confirmation rule (review order → confirm order) as required by Moroccan e-commerce law.

4.3 RGPD / GDPR Cross-Compliance

If your website targets or processes data from EU citizens (common for Moroccan businesses with European clients), you must also comply with GDPR:

• Cookie Consent Banner: Implement a compliant cookie consent mechanism that blocks non-essential cookies until the user provides affirmative consent.
• Privacy Policy in Multiple Languages: Publish a comprehensive privacy policy in all languages your site serves.
• Data Processing Agreements (DPA): Ensure all third-party service providers (analytics, hosting, email) have signed DPAs guaranteeing GDPR-level protections.

---

5. Application Security Pre-Launch Audit

• Dependency Vulnerability Scan: Run npm audit, pip audit, or equivalent to identify and patch known vulnerabilities in third-party libraries before deployment.
• Static Application Security Testing (SAST): Use automated code scanning tools (SonarQube, Semgrep) to detect injection flaws, hardcoded secrets, and insecure patterns in your source code.
• Secrets Management: Ensure no API keys, database credentials, or private keys are committed to your codebase. Use environment variables or dedicated secrets managers (HashiCorp Vault, AWS Secrets Manager).
• Error Handling: Disable stack traces and verbose error messages in production. Return generic error pages to users while logging detailed errors server-side.
• Directory Listing Disabled: Verify that your web server does not expose directory listings. Configure Options -Indexes (Apache) or autoindex off (Nginx).

---

6. Backup & Incident Response Readiness

• Automated Backups: Configure daily automated backups of your database, application code, and server configurations. Store backups in a geographically separate location.
• Backup Restoration Testing: A backup that has never been tested is not a backup. Perform a full restoration drill at least once before launch.
• Incident Response Plan: Prepare a written incident response playbook defining roles, communication channels, and escalation procedures for security incidents.
• Monitoring & Alerting: Set up uptime monitoring, SSL certificate expiration alerts, and anomaly detection on critical endpoints.

---

Download the Complete Checklist