A step-by-step guide to securing Sitecore Headless and Next.js applications with enterprise-grade techniques, including cookie security, CORS, HTTP headers, and internal API protection.
Start typing to search...
In today's digital landscape, web application security isn't just a nice-to-have—it's absolutely critical. When we conducted a security assessment of our Next.js Progressive Web Application (PWA), we discovered multiple vulnerabilities that could expose user data and compromise system integrity.
This comprehensive guide walks you through our complete security hardening process, transforming a standard Next.js application into an enterprise-grade, security-hardened platform. We'll cover every step, from identifying vulnerabilities to implementing robust security measures that protect against modern web threats.
What You'll Learn:
Our security assessment revealed 12 critical vulnerabilities across 4 major categories:
| Risk Level | Issue Type | Count | Impact |
|---|---|---|---|
| Medium | Cookie with Missing SameSite Attribute | 8 | CSRF attacks, cookie leakage |
| Medium | Missing Secure Attribute in SSL Cookies | 1 | Session hijacking |
| Low | Permanent Sensitive Cookies | 1 | Data persistence risks |
| Low | Unnecessary HTTP Headers | 2 | Information disclosure |
High-Impact Vulnerabilities:
These vulnerabilities could lead to:
Default Next.js and NextAuth configurations often lack proper security attributes, leaving applications vulnerable to various attacks.
File: src/pages/api/auth/[...nextauth].ts
export const authOptions: NextAuthOptions = {
// ... existing configuration
cookies: {
sessionToken: {
name: `__Secure-next-auth.session-token`,
options: {
httpOnly: true, // Prevents XSS attacks
sameSite: "lax", // CSRF protection
path: "/",
secure: true, // HTTPS-only transmission
domain: process.env.NEXTAUTH_URL
? new URL(process.env.NEXTAUTH_URL).hostname
: undefined,
},
},
callbackUrl: {
name: `__Secure-next-auth.callback-url`,
options: {
httpOnly: true,
sameSite: "lax",
path: "/",
secure: true,
domain: process.env.NEXTAUTH_URL
? new URL(process.env.NEXTAUTH_URL).hostname
: undefined,
},
},
csrfToken: {
name: `__Host-next-auth.csrf-token`,
options: {
httpOnly: true,
sameSite: "lax",
path: "/",
secure: true,
},
},
// ... additional cookie configurations
},
};2. Cookie Utility Functions
File: src/utils/cookie.ts
export interface SecureCookieOptions {
httpOnly?: boolean;
secure?: boolean;
sameSite?: "strict" | "lax" | "none";
maxAge?: number;
expires?: Date;
path?: string;
domain?: string;
}
export const DEFAULT_SECURE_COOKIE_OPTIONS: SecureCookieOptions = {
httpOnly: true,
secure: true,
sameSite: "lax",
path: "/",
domain: process.env.NEXTAUTH_URL
? new URL(process.env.NEXTAUTH_URL).hostname
: undefined,
};
export function createSecureCookieOptions(
options: Partial<SecureCookieOptions> = {}
): SecureCookieOptions {
return {
...DEFAULT_SECURE_COOKIE_OPTIONS,
...options,
};
}
✅ XSS Prevention: HttpOnly attribute blocks client-side script access
✅ CSRF Protection: SameSite attribute prevents cross-site request abuse
✅ Secure Transmission: Secure flag enforces HTTPS-only communication
✅ Enhanced Security: Cookie prefixes (__Secure-, __Host-) provide additional browser-level protection
Without proper CORS configuration, external websites could potentially make unauthorized requests to your API endpoints from users' browsers.
File: next.config.js
async headers() {
return [
{
source: '/api/:path*',
headers: [
{
key: 'Access-Control-Allow-Origin',
value: process.env.NEXTAUTH_URL, // Environment-aware domain
},
{
key: 'Access-Control-Allow-Credentials',
value: 'true', // Preserve authentication cookies
},
{
key: 'Access-Control-Allow-Methods',
value: 'GET, POST, PUT, DELETE, OPTIONS',
},
{
key: 'Access-Control-Allow-Headers',
value: 'Content-Type, Authorization, X-Requested-With',
},
],
},
// ... other headers
];
}
What CORS Blocks:
What CORS Allows:
Default server headers expose sensitive information about your technology stack, making it easier for attackers to target specific vulnerabilities.
File: next.config.js
async headers() {
return [
{
source: '/(.*)',
headers: [
{
key: 'Content-Security-Policy',
value: [
"default-src 'self'",
"script-src 'self' 'unsafe-inline' 'unsafe-eval' <https://trusted-domains.com>",
"style-src 'self' 'unsafe-inline' <https://fonts.googleapis.com>",
"font-src 'self' <https://fonts.gstatic.com>",
"img-src 'self' data: blob: https: http:",
"connect-src 'self' https: wss:",
"frame-src 'self' <https://trusted-domains.com>",
"object-src 'none'",
"base-uri 'self'",
"form-action 'self'",
].join('; '),
},
{
key: 'Strict-Transport-Security',
value: 'max-age=31536000; includeSubDomains; preload',
},
{
key: 'X-Frame-Options',
value: 'SAMEORIGIN',
},
{
key: 'X-Content-Type-Options',
value: 'nosniff',
},
{
key: 'Referrer-Policy',
value: 'strict-origin-when-cross-origin',
},
{
key: 'Server',
value: '', // Remove server information
},
{
key: 'X-Powered-By',
value: '', // Remove technology stack information
},
],
},
];
}
✅ Information Hiding: Removes server and technology fingerprinting
✅ Content Security: CSP prevents XSS and injection attacks
✅ Transport Security: HSTS enforces HTTPS connections
✅ Frame Protection: Prevents clickjacking attacks
While NextAuth provides session-based authentication, additional protection layers can prevent even authenticated users from accessing APIs through external tools.
1. Environment Configuration
# .env.local
INTERNAL_API_SECRET=your-super-secret-internal-token-here-make-it-long-and-random-256-bits2. API Endpoint Protection
File: src/pages/api/sampleProject/profileDetails.ts
import { NextApiRequest, NextApiResponse } from "next";
import { getToken } from "next-auth/jwt";
export default async function handler(
req: NextApiRequest,
res: NextApiResponse
) {
if (req.method !== "POST") {
return res.status(405).json({ message: "Method Not Allowed" });
}
// Internal API protection - only allow calls from Next.js app
const internalToken = req.headers["x-internal-token"];
if (internalToken !== process.env.INTERNAL_API_SECRET) {
return res.status(403).json({ message: "Forbidden: Internal API only" });
}
// NextAuth session validation
const token = await getToken({ req });
if (!token) {
return res.status(401).json({ message: "Unauthorized: No valid session" });
}
// Your API logic here
try {
// ... existing API implementation
return res.status(200).json(response.data);
} catch (error) {
console.error("API Error:", error);
return res.status(500).json({ message: "Internal Server Error" });
}
}3. Client-Side API Utility
File: src/utils/internalApi.ts
interface InternalApiOptions {
method?: "GET" | "POST" | "PUT" | "DELETE";
body?: any;
headers?: Record<string, string>;
}
export async function internalApiCall(
endpoint: string,
options: InternalApiOptions = {}
): Promise<Response> {
const { method = "POST", body, headers = {} } = options;
return fetch(endpoint, {
method,
headers: {
"Content-Type": "application/json",
"x-internal-token": process.env.NEXT_PUBLIC_INTERNAL_API_SECRET || "",
...headers,
},
body: body ? JSON.stringify(body) : undefined,
credentials: "include", // Include NextAuth cookies
});
}
// Usage example
export async function getProfileDetails() {
const response = await internalApiCall("/api/sampleProject/profileDetails");
if (!response.ok) {
throw new Error(`Profile details failed: ${response.statusText}`);
}
return response.json();
}
Security Layers:
Use Cases:
Sitecore JSS uses its own middleware system, and we need to ensure our security enhancements don't conflict with existing functionality.
File: src/lib/middleware/plugins/internal-api.ts
import { NextResponse } from "next/server";
import type { NextFetchEvent, NextRequest } from "next/server";
import { MiddlewarePlugin } from "..";
class InternalApiPlugin implements MiddlewarePlugin {
order = 5; // Run after site resolution but before other plugins
async exec(req: NextRequest, res?: NextResponse): Promise<NextResponse> {
// Only apply to custom API routes (not Sitecore APIs)
if (
req.nextUrl.pathname.startsWith("/api/sampleProject/") ||
req.nextUrl.pathname.startsWith("/api/biometrics/") ||
req.nextUrl.pathname.startsWith("/api/session/")
) {
const requestHeaders = new Headers(req.headers);
requestHeaders.set(
"x-internal-token",
process.env.INTERNAL_API_SECRET || ""
);
return NextResponse.next({
request: { headers: requestHeaders },
});
}
return res || NextResponse.next();
}
}
export default new InternalApiPlugin();
✅ Non-Conflicting: Only targets custom API routes, leaves Sitecore APIs untouched
✅ Plugin Architecture: Uses Sitecore JSS's official middleware system
✅ Ordered Execution: Runs at the appropriate time in the middleware chain
✅ Automatic Token Injection: No code changes required in existing API calls
Selective Targeting:
/api/editing/, /sitecore/api/) remain unmodified/api/sampleProject/) get enhanced securityZero Breaking Changes:
Overall System Architecture
The hardened system now operates with multiple layers of security, integrating Sitecore JSS, Next.js, and secure API communications:
This architecture illustrates how secure cookies, JWT validation, CORS protection, and API utilities integrate into a modular, maintainable design using hooks, SWR, and environment-aware configuration.
The following sequence diagram shows how secure data flows through the system from user interaction to API response:
useProfileDetails hook integrates with secure cookie utilities and error handlinggetSecureToken() to validate session cookies with proper security attributes| Issue Category | Before | After | Status |
|---|---|---|---|
| Cookie SameSite Missing | 8 issues | 0 issues | ✅ RESOLVED |
| Missing Secure Attribute | 1 issue | 0 issues | ✅ RESOLVED |
| Permanent Sensitive Cookies | 1 issue | 0 issues | ✅ RESOLVED |
| Information Disclosure Headers | 2 issues | 0 issues | ✅ RESOLVED |
Before Implementation:
After Implementation:
✅ Minimal Overhead: Security headers add <1ms to response time
✅ No Breaking Changes: 100% backward compatibility maintained
✅ Improved Caching: Secure cookies enable better browser caching
Always Use Secure Attributes:
const secureOptions = {
httpOnly: true, // Prevent XSS
secure: true, // HTTPS only
sameSite: "lax", // CSRF protection
path: "/", // Appropriate scope
};
Cookie Naming Conventions:
__Secure- prefix for secure cookies__Host- prefix for host-locked cookiesEnvironment-Specific Origins:
const allowedOrigins = {
development: "<http://localhost:3000>",
staging: "<https://staging.yourapp.com>",
production: "<https://yourapp.com>",
};
Credential Handling:
Access-Control-Allow-Credentials: true for authenticated APIsToken Generation:
# Generate a secure random token
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
Token Validation:
// Always use constant-time comparison
const crypto = require("crypto");
function validateToken(provided: string, expected: string): boolean {
return crypto.timingSafeEqual(Buffer.from(provided), Buffer.from(expected));
}
Regular Security Audits:
Logging and Alerting:
// Log security events
console.log("Security Event:", {
type: "unauthorized_access_attempt",
ip: req.ip,
endpoint: req.url,
timestamp: new Date().toISOString(),
});
Planned Improvements:
This comprehensive security hardening implementation transformed our Next.js application from a standard configuration with multiple vulnerabilities to an enterprise-grade, security-hardened platform. By addressing cookie security, implementing CORS protection, hardening HTTP headers, and adding internal API authentication, we've created a robust defense against modern web threats.
✅ 100% Vulnerability Resolution: All 12 security issues eliminated
✅ Zero Breaking Changes: Full backward compatibility maintained
✅ Enterprise-Grade Security: OWASP and industry standards compliance
✅ Future-Proof Architecture: Scalable and maintainable security implementation
In today's threat landscape, security isn't optional—it's fundamental. This implementation provides:
Immediate Benefits:
Long-Term Value:
This implementation serves as a blueprint for securing any Next.js application. The principles and patterns demonstrated here can be adapted and extended based on your specific security requirements and threat model.