Web Security Checklist for Startups

Unencrypted HTTP traffic exposes your users to eavesdropping, credential theft, and man-in-the-middle attacks. Every page and every API endpoint must be served over HTTPS. Sensagraph automatically checks whether your site enforces HTTPS and whether your TLS configuration is secure.

• Obtain a TLS certificate from a trusted Certificate Authority (Let's Encrypt is free and widely trusted).
• Configure your web server to redirect all HTTP requests (port 80) to HTTPS (port 443) with a 301 permanent redirect.
• Enable HTTP Strict Transport Security (HSTS) by adding the header Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.
• Submit your domain to the HSTS preload list at hstspreload.org once you are confident in your HTTPS setup.
• Disable outdated TLS versions (TLS 1.0 and 1.1); support only TLS 1.2 and TLS 1.3.
• Disable weak cipher suites (e.g., RC4, 3DES, NULL ciphers) in your server configuration.
• Ensure your TLS certificate is renewed before expiry — use automated renewal (e.g., Certbot with a cron job or systemd timer).
• Check that all mixed content (HTTP resources loaded on HTTPS pages) is eliminated.

Weak authentication is one of the most exploited attack vectors. Properly implemented login systems and session handling dramatically reduce the risk of account takeover.

• Enforce a minimum password length of at least 12 characters; consider checking passwords against known-breached password lists (e.g., using the HaveIBeenPwned API).
• Hash passwords with a strong, slow hashing algorithm: bcrypt, scrypt, or Argon2. Never use MD5 or SHA-1 for passwords.
• Implement multi-factor authentication (MFA) — at minimum, offer TOTP-based MFA (e.g., via Google Authenticator) and consider making it mandatory for admin accounts.
• Rate-limit login attempts to prevent brute-force attacks; lock accounts temporarily after repeated failures and alert the user.
• Generate session tokens with a cryptographically secure random number generator; ensure they are at least 128 bits of entropy.
• Set session cookies with the HttpOnly, Secure, and SameSite=Strict (or Lax) attributes.
• Invalidate session tokens server-side on logout; do not rely solely on deleting the cookie on the client.
• Implement absolute and idle session timeouts appropriate to your risk level (e.g., 30-minute idle timeout for sensitive applications).
• Use OAuth 2.0 / OpenID Connect for third-party authentication rather than building custom SSO from scratch.
• Protect password reset flows: use short-lived, single-use tokens sent to a verified email address; never send passwords in plain text.

Injection vulnerabilities remain at the top of every web security risk list. A single unparameterised query can expose or destroy your entire database. These are non-negotiable fixes.

• Use parameterised queries or prepared statements for every database interaction — never concatenate user input into SQL strings.
• Use an ORM (Object-Relational Mapper) carefully; even ORMs can be misused to produce raw queries, so audit any raw query methods.
• Validate all user input on the server side: check type, length, format, and range before processing.
• Whitelist expected input values wherever possible rather than blacklisting bad characters.
• Escape output correctly for the context in which it is rendered (HTML, JavaScript, CSS, URL) to prevent Cross-Site Scripting (XSS).
• Avoid passing user-supplied data to OS shell commands; if unavoidable, use strict allowlists and shell-escape functions.
• Review NoSQL queries (MongoDB, etc.) for operator injection; validate and sanitise keys as well as values.
• Run automated scans regularly to detect injection points that may have been introduced through new code. Sensagraph scans for common injection vulnerabilities continuously.

Security headers are a fast, low-effort layer of defence that instruct browsers to refuse dangerous behaviours. Many startups skip them entirely — don't be one of them. Sensagraph checks for the presence and correctness of key security headers on every scan.

• Set a Content Security Policy (CSP) header to restrict which sources can load scripts, styles, images, and other resources. Start with a strict policy and loosen as needed: Content-Security-Policy: default-src 'self';
• Add X-Frame-Options: DENY (or SAMEORIGIN) to prevent your pages from being embedded in iframes on other sites (clickjacking defence).
• Add X-Content-Type-Options: nosniff to prevent browsers from MIME-type sniffing responses away from the declared content type.
• Set Referrer-Policy: strict-origin-when-cross-origin to control how much referrer information is sent with requests.
• Add Permissions-Policy (formerly Feature-Policy) to disable browser features your app does not use (e.g., camera, microphone, geolocation).
• Remove or suppress server banner headers (Server, X-Powered-By, X-AspNet-Version) that reveal your technology stack to attackers.
• Test your headers using securityheaders.com and aim for an A or A+ rating.

Most modern web apps are 80–90% third-party code. A vulnerability in an npm package, a Python library, or a JavaScript CDN dependency can compromise your entire application — even if your own code is perfect.

• Maintain an up-to-date inventory of all direct and transitive dependencies for your project.
• Run npm audit (Node.js), pip audit (Python), bundler-audit (Ruby), or equivalent for your stack, and fix critical and high-severity findings immediately.
• Integrate dependency scanning into your CI/CD pipeline so vulnerabilities are caught before code reaches production.
• Pin dependency versions in your lock files (package-lock.json, Pipfile.lock, etc.) and review changes to those files in pull requests.
• Avoid loading third-party JavaScript directly from external CDNs without Subresource Integrity (SRI) attributes; add integrity and crossorigin attributes to <script> and <link> tags.
• Vet third-party vendors and services for their own security practices before granting them access to your users' data.
• Set up automated alerts (e.g., GitHub Dependabot or Snyk) to notify you of new vulnerabilities in your dependencies.
• Remove unused dependencies — every extra package is a potential attack surface.

Every user, service account, and API key should have only the minimum permissions required to do its job. Over-privileged accounts are a favourite target for attackers — once compromised, they cause maximum damage.

• Implement Role-Based Access Control (RBAC): define roles (e.g., viewer, editor, admin) and assign the minimum necessary permissions to each.
• Never use root or superuser database credentials in your application; create a dedicated database user with only SELECT, INSERT, UPDATE, DELETE on the specific tables it needs.
• Rotate API keys, secrets, and credentials regularly. Revoke any that are no longer needed.
• Store secrets in a dedicated secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager, or environment variables in a secure CI system) — never hard-code them in source code or commit them to version control.
• Audit your codebase and git history for accidentally committed secrets using tools like git-secrets or truffleHog.
• Apply IP allowlisting to administrative interfaces and dashboards wherever operationally feasible.
• Enforce MFA for all admin-level accounts and any accounts with access to production systems.
• Review and revoke access for employees, contractors, and services promptly when they no longer need it (offboarding process).

Data breaches are among the most damaging events a startup can face — financially, legally, and reputationally. Treating sensitive data with care from the start is far cheaper than dealing with the aftermath of a breach.

• Identify and classify all sensitive data your application handles: PII, payment data, health data, credentials, and business-critical data.
• Encrypt sensitive data at rest using AES-256 or equivalent; ensure database encryption is enabled at the storage level.
• Encrypt sensitive data in transit (covered by HTTPS) and between internal services (use mutual TLS or encrypted channels even for internal microservices).
• Do not store data you do not need — apply data minimisation principles. If you don't collect it, it can't be stolen.
• Never log sensitive fields such as passwords, full credit card numbers, social security numbers, or session tokens — audit your logging statements.
• Mask or truncate sensitive data in logs, error messages, and analytics (e.g., show only the last four digits of a card number).
• Define and document a data retention policy; delete data that is no longer required by your business or legal obligations.
• If you process payment card data, ensure you are PCI-DSS compliant (or use a PCI-compliant payment processor like Stripe to minimise scope).
• Ensure your privacy policy accurately reflects your data practices and complies with applicable regulations (GDPR, CCPA, etc.).

You cannot defend what you cannot see. Comprehensive logging and real-time alerting allow you to detect attacks in progress, investigate incidents after the fact, and demonstrate compliance to auditors.

• Log all authentication events: successful logins, failed logins, password resets, MFA challenges, and account lockouts — including IP address, timestamp, and user agent.
• Log all authorisation failures (access to resources a user does not have permission to view).
• Log all administrative actions: user role changes, configuration changes, data exports.
• Centralise logs in a tamper-resistant log management system (e.g., a SIEM, or a managed service such as Datadog, Splunk, or the ELK stack).
• Set up real-time alerts for high-severity events: multiple failed login attempts from a single IP, privilege escalation, unusual data export volumes, or access from unexpected geographies.
• Ensure logs are retained for a sufficient period (typically 90 days to 1 year, depending on your compliance requirements).
• Protect your logs — ensure they cannot be deleted or modified by a compromised application account.
• Test your alerting pipeline regularly to confirm alerts actually fire and reach the right people.

Application-level security is not enough if your servers, cloud configuration, or CI/CD pipeline are insecure. Attackers routinely exploit misconfigured cloud storage, open admin ports, and compromised build systems.

• Disable all unnecessary services and close all unused ports on your servers; use a firewall (e.g., AWS Security Groups, GCP Firewall Rules, or UFW on Linux) to enforce this.
• Never expose administrative interfaces (SSH, database ports, admin dashboards) directly to the public internet — use a VPN or bastion host.
• Use SSH key-based authentication for server access; disable password-based SSH login (PasswordAuthentication no in sshd_config).
• Keep your server operating systems and all installed packages up to date; enable automatic security updates for critical patches.
• Audit cloud storage permissions (S3 buckets, GCS buckets, Azure Blob Storage) to ensure no buckets are publicly readable unless explicitly intended.
• Scan container images for known vulnerabilities before deploying them (e.g., using Docker Scout, Trivy, or Snyk Container).
• Use infrastructure-as-code (Terraform, Pulumi, CloudFormation) and review infrastructure changes through pull requests, just as you would application code.
• Secure your CI/CD pipeline: restrict who can merge to production branches, use signed commits, and ensure build secrets are not exposed in logs.
• Enable cloud provider audit logs (AWS CloudTrail, GCP Cloud Audit Logs, Azure Monitor) and alert on suspicious API calls.

Security is not a one-time event. New vulnerabilities are discovered every day — in your code, your dependencies, and your configuration. Continuous automated scanning ensures you find issues before attackers do and gives you an ongoing measure of your security posture.

• Schedule regular automated security scans of your web application and public-facing infrastructure — at minimum weekly, ideally on every deployment.
• Triage and prioritise findings by severity: fix critical and high-severity issues immediately; schedule medium and low severity items in your normal sprint cycle.
• Perform a manual penetration test at least once a year, or after major architectural changes — automated scanning complements but does not replace human expertise.
• Set up a responsible disclosure policy or bug bounty programme so external researchers can report vulnerabilities to you safely.
• Track your vulnerability remediation metrics over time to demonstrate improving security posture to investors, enterprise customers, and auditors.
• Sensagraph provides continuous automated scanning of your web application, flagging new vulnerabilities as your site evolves — keeping your security posture up to date without manual effort.