Ongoing Website Security Monitoring Checklist

You cannot monitor what you do not know exists. Start by mapping every public-facing asset. Forgotten subdomains, staging environments, and shadow APIs are frequent entry points for attackers.

• List every domain and subdomain associated with your organisation (e.g., app.example.com, api.example.com, staging.example.com).
• Identify all public IP addresses and hosting environments (cloud, VPS, shared hosting).
• Catalogue all APIs — REST, GraphQL, and third-party integrations — that are externally reachable.
• Remove or password-protect any staging, test, or development environments that are publicly accessible.
• Repeat this inventory check at least monthly or whenever new assets are deployed.

An expired or misconfigured SSL/TLS certificate instantly breaks user trust, triggers browser warnings, and can expose data in transit. Certificate issues are entirely preventable with proactive monitoring. Sensagraph continuously checks certificate validity and expiry across all your monitored domains.

• Set up automated alerts for certificate expiry at least 30 days before the expiration date.
• Verify that your certificate chain is complete and trusted by major browsers.
• Ensure TLS 1.2 is the minimum supported protocol; disable TLS 1.0 and TLS 1.1.
• Confirm weak cipher suites (e.g., RC4, DES, 3DES) are disabled on your server.
• Check that HTTPS is enforced site-wide and HTTP requests redirect to HTTPS automatically.
• Enable HSTS (HTTP Strict Transport Security) with a minimum max-age of 31536000 seconds.

Point-in-time security assessments are not enough. Your attack surface changes with every deployment, dependency update, or configuration change. Automated, recurring scans ensure newly introduced vulnerabilities are detected quickly. Sensagraph performs automated vulnerability scans on a continuous basis across your registered assets.

• Schedule automated scans to run at least weekly — daily is preferable for high-traffic or sensitive applications.
• Trigger an additional scan after every significant deployment or infrastructure change.
• Prioritise findings by severity (Critical, High, Medium, Low) and set SLAs for remediation (e.g., Critical within 24 hours).
• Track vulnerability trends over time to confirm that your fixes are sticking.
• Ensure all scan results are documented and reviewed by a responsible team member.

HTTP security headers are a lightweight but highly effective defence layer. Missing or misconfigured headers leave your application exposed to clickjacking, cross-site scripting, MIME sniffing, and other attacks. Sensagraph automatically audits HTTP response headers on every scan.

• Set Content-Security-Policy (CSP) to restrict sources of scripts, styles, images, and other resources.
• Enable Strict-Transport-Security (HSTS) to force HTTPS connections.
• Add X-Frame-Options: DENY or SAMEORIGIN to prevent clickjacking.
• Set X-Content-Type-Options: nosniff to stop MIME-type sniffing attacks.
• Configure Referrer-Policy to control how much referrer information is shared.
• Add Permissions-Policy to restrict access to browser features like camera, microphone, and geolocation.
• Remove server version headers (e.g., Server, X-Powered-By) to limit information leakage.

Outdated CMS platforms, plugins, frameworks, and server software are the leading cause of website compromises. Attackers actively scan for known CVEs in popular software. Keeping everything up to date is one of the highest-ROI security actions you can take.

• Enable automatic security updates for your operating system and web server software (e.g., Nginx, Apache).
• Subscribe to security advisories for every CMS, framework, or major library you use (WordPress, Drupal, Laravel, Django, etc.).
• Use a dependency management tool (npm audit, pip-audit, Composer, Dependabot) to flag vulnerable packages.
• Remove unused plugins, themes, and libraries — they still represent risk even if inactive.
• Document the version of every critical component and review it monthly.
• Test updates in a staging environment before deploying to production.

Weak or excessive access permissions are a major risk. Admin panels, database interfaces, and deployment pipelines left unprotected or with default credentials are easy targets. Conduct a regular access review to ensure the principle of least privilege is enforced.

• Audit all user accounts quarterly — remove accounts for former employees and contractors immediately upon offboarding.
• Enforce multi-factor authentication (MFA) for all admin, CMS, and cloud platform logins.
• Restrict admin interfaces (e.g., /wp-admin, /phpmyadmin) to specific IP ranges or VPN access only.
• Ensure no default credentials (admin/admin, root/root) exist on any system or service.
• Implement account lockout or CAPTCHA after a defined number of failed login attempts.
• Review and limit API key permissions — apply the principle of least privilege to all service accounts.
• Log all admin actions and review logs for unexpected activity weekly.

Sensitive data exposure often happens unintentionally — through misconfigured cloud storage buckets, accidentally committed credentials, or verbose error messages. Regular checks prevent what can be an embarrassing and costly breach.

• Scan your public web root and repository history for accidentally exposed API keys, passwords, or private keys.
• Ensure cloud storage buckets (AWS S3, Google Cloud Storage, Azure Blob) are not publicly readable unless explicitly intended.
• Configure your application to display generic error messages to users — never expose stack traces, database errors, or file paths in production.
• Check that .env files, .git directories, backup files (.sql, .bak), and config files are blocked from public access.
• Verify that any sensitive data stored in cookies is encrypted and marked HttpOnly and Secure.
• Use a secrets management tool (e.g., HashiCorp Vault, AWS Secrets Manager) rather than hardcoding credentials in source code.

The OWASP Top 10 represents the most critical and commonly exploited web application vulnerabilities. Testing for these on a regular basis — not just at launch — is essential for any serious web application.

• SQL Injection: Ensure all user inputs are parameterised or use prepared statements; never concatenate raw input into queries.
• Cross-Site Scripting (XSS): Encode all output rendered in the browser; use a strict Content Security Policy.
• Broken Access Control: Test that authenticated users cannot access resources belonging to other users by manipulating IDs or paths.
• Security Misconfiguration: Remove default accounts, unnecessary features, and verbose error messages from production environments.
• Insecure Direct Object References (IDOR): Verify that every resource access request is authorised server-side, not just hidden in the UI.
• Cross-Site Request Forgery (CSRF): Implement and validate CSRF tokens for all state-changing requests.
• Sensitive Data Exposure: Confirm all sensitive data is encrypted in transit and at rest.
• Using Components with Known Vulnerabilities: Refer to Step 05 for dependency management practices.

Logs are your most valuable forensic tool — but only if you collect them centrally and actually review them. Effective alerting means you know about an incident as it happens, not days later.

• Centralise logs from your web server, application, database, and firewall in a single log management platform (e.g., ELK Stack, Splunk, Datadog, Graylog).
• Retain logs for a minimum of 90 days — 12 months is recommended for compliance-sensitive environments.
• Set up real-time alerts for: repeated failed login attempts, sudden traffic spikes, 4xx/5xx error surges, and changes to admin accounts.
• Monitor for unusual geographic access patterns — logins or requests from unexpected countries or IP ranges.
• Review access logs at least weekly for anomalies such as path traversal attempts, unusual query strings, or scanning patterns.
• Ensure your logging system itself is secured and logs cannot be deleted or tampered with by an attacker who gains access.

Even with the best monitoring, incidents can and do happen. A documented, tested incident response plan means the difference between a minor event and a major breach. Do not wait until an attack is in progress to figure out what to do.

• Document a step-by-step incident response procedure covering: detection, containment, eradication, recovery, and post-incident review.
• Assign clear roles and responsibilities — who leads the response, who communicates with stakeholders, who contacts hosting providers.
• Keep an offline or out-of-band copy of your incident response plan accessible even if your systems are compromised.
• Run a tabletop exercise at least once per year to simulate a breach scenario and identify gaps in your plan.
• Maintain an up-to-date contact list: hosting provider support, domain registrar, legal counsel, and relevant regulatory bodies.
• Define your breach notification obligations under applicable regulations (GDPR, HIPAA, PCI-DSS) and know your reporting deadlines.
• After any real incident, conduct a blameless post-mortem and update your monitoring checklist accordingly.