Website Security Best Practices for 2026

Implement authentication correctly using established libraries — never roll your own crypto. Use passkeys or TOTP-based multi-factor authentication for anything beyond casual accounts. Store passwords using Argon2id or bcrypt with a cost factor calibrated to your server hardware. Set session cookies with HttpOnly, Secure, and SameSite=Strict attributes. Rotate session tokens after privilege escalation events (login, password change, role change).

Passkeys deserve particular attention in 2026 because they eliminate the largest single attack surface in consumer web applications: phishable passwords. A passkey is a cryptographic credential stored on the user's device and tied to the specific domain — it cannot be phished because it only works on the site it was created for. Major Indian platforms including some banking portals have begun passkey rollouts. For new applications targeting tech-savvy users, implementing passkey support via the WebAuthn API (or via Clerk/Auth.js which abstract it) is now a realistic first-class authentication option, not an experimental feature.

For multi-tenant SaaS applications, token isolation between tenants is critical. Ensure that JWTs or session tokens include a tenant identifier claim that is validated on every protected API route — not just at login. A common vulnerability pattern is an application that correctly authenticates users but fails to enforce tenant boundaries on data queries, allowing a user from Tenant A to access Tenant B's data by manipulating resource IDs in API calls. This class of vulnerability (Broken Object Level Authorization, or BOLA) is consistently the top-ranked API vulnerability in the OWASP API Security Top 10.

A well-configured Content Security Policy (CSP) prevents XSS attacks by restricting which scripts can execute on your pages. Pair it with other security headers: Strict-Transport-Security (HSTS) forces HTTPS, X-Frame-Options prevents clickjacking, and Permissions-Policy restricts access to browser APIs. Use Mozilla Observatory or securityheaders.com to audit your current headers and identify gaps.

Implementing a strict CSP in a Next.js application requires some care because Next.js inlines scripts for hydration. The recommended approach is nonce-based CSP: generate a cryptographic nonce per request in your middleware, inject it into the CSP header, and configure Next.js to include the nonce on its inline scripts via the nonce prop in your custom Document. This allows a strict script-src policy that blocks all unsigned inline scripts while still allowing Next.js's hydration scripts.

For the Permissions-Policy header, be deliberate about which browser APIs you expose. A policy like camera=(), microphone=(), geolocation=() disables these APIs entirely unless your application actually needs them. This is defence in depth: even if an XSS vulnerability were exploited, the attacker could not use it to silently access the user's camera or microphone. Review your Permissions-Policy annually as your application's feature set evolves.

The single most underappreciated attack vector in modern web applications is third-party dependencies. Run npm audit or equivalent weekly. Pin your dependencies to exact versions in CI. Use tools like Socket.dev or Snyk to monitor for newly discovered vulnerabilities. In 2025, supply chain attacks accounted for over 23% of incidents affecting web applications.

The 2024-2025 wave of supply chain attacks — where malicious code was injected into widely-used npm packages — demonstrated that even well-maintained packages are not immune. The polyfill.io compromise affected hundreds of thousands of websites that loaded third-party JavaScript from a CDN that changed ownership. The lesson: do not load JavaScript from third-party CDNs you do not control. Self-host all JavaScript dependencies or load them from your own CDN bucket.

For packages you do depend on, implement Subresource Integrity (SRI) for any third-party scripts you cannot self-host — the browser will refuse to execute a script whose hash does not match the expected value, preventing tampering even if the CDN is compromised. Use npm's package-lock.json or pnpm's lockfile to ensure reproducible installs, and configure your CI pipeline to fail if the lockfile has been tampered with relative to the checked-in version.

Encrypt sensitive data at rest using AES-256 and in transit using TLS 1.3. Apply the principle of least privilege to database accounts — your web app should not connect to the database as a superuser. Log access to sensitive data and set up alerts for anomalous patterns. Under India's Digital Personal Data Protection Act (DPDPA), maintaining proper data handling records is also now a legal requirement.

India's DPDPA, which came into full enforcement force in 2025, introduces specific requirements that many web applications built before 2024 are not compliant with. These include: obtaining explicit, granular consent before collecting personal data (not buried in terms of service), providing a clear mechanism for users to withdraw consent and request data deletion, appointing a Data Protection Officer for organisations above a certain threshold, and maintaining records of all data processing activities. Non-compliance carries penalties up to ₹250 crore per breach instance.

For practical DPDPA compliance in a web application: implement a consent management system that records what the user consented to and when (a database table with user ID, consent type, timestamp, and version of the privacy policy accepted is sufficient for most applications). Build a data deletion endpoint that removes or anonymises all personally identifiable information linked to a user account. Document your data flows — which third-party services receive user data, what data is stored where, and for how long. This documentation is a DPDPA requirement, but it is also genuinely useful operational knowledge that most engineering teams lack.

Application-level security is incomplete without infrastructure-level protection. Every public API endpoint should have rate limiting applied — not just your authentication routes. An API that allows unlimited product search queries, for example, can be scraped to extract your entire catalogue or used for competitor price monitoring at scale. Use a sliding window rate limiter (Upstash's rate limit library is the easiest implementation for Next.js) with limits calibrated to legitimate user behaviour patterns.

For bot protection beyond rate limiting, Cloudflare's Turnstile (a privacy-preserving CAPTCHA alternative) and hCaptcha are the 2026 defaults. Avoid reCAPTCHA v3 for new implementations — its privacy implications conflict with GDPR and DPDPA compliance requirements. Turnstile runs entirely client-side with no user interaction in most cases, making it both less friction-inducing and more privacy-respecting than alternatives.

On the infrastructure side, ensure your database and Redis instances are not publicly accessible — they should only accept connections from your application servers via a private network or VPC. Cloud providers like AWS, GCP, and Supabase make this straightforward through security group and VPC configuration. A database that is reachable on the public internet with only a password protecting it is one credential leak away from a total data breach.