Astro's zero-JS-by-default architecture is a security win, but developers often break this isolation by leaking sensitive environment variables to the client-side or failing to implement proper security headers in SSR mode. The most critical misconfiguration occurs when secrets are prefixed with 'PUBLIC_', making them accessible to any browser-side script and easily harvestable by attackers.

The Vulnerable Pattern

--- 
// src/components/Vulnerable.astro
// DANGER: The PUBLIC_ prefix tells Astro to bundle this into the client-side JS
const apiKey = import.meta.env.PUBLIC_AWS_SECRET_KEY; 
---
Upload

The Secure Implementation

Astro uses a strict naming convention for environment variables: only variables prefixed with 'PUBLIC_' are exposed to the client-side bundle. To fix this misconfiguration: 1. Audit your .env files and remove the 'PUBLIC_' prefix from any sensitive credentials (API keys, DB URIs, private tokens). 2. Ensure sensitive logic stays within the Astro frontmatter (the code between the '---' fences), which executes only during build time or on the server. 3. For SSR deployments, use your adapter's configuration (e.g., @astrojs/node or @astrojs/vercel) to set 'Strict-Transport-Security' and 'Content-Security-Policy' headers to prevent man-in-the-middle and cross-site scripting attacks.

--- 
// src/components/Secure.astro
// 1. Remove 'PUBLIC_' prefix in .env to keep it server-side only
// 2. Access variables in the frontmatter (server-side context)
const secretKey = import.meta.env.AWS_SECRET_KEY;
// Handle sensitive logic exclusively on the server
const data = await fetchSecureData(secretKey);

Data processed on server
{data.result}