Fix Improper Assets Management in Gatsby

Gatsby's static generation model often leads to 'Asset Leakage' where developers inadvertently expose sensitive files or environment variables. By default, anything in the /static folder is copied to the public root, and any environment variable prefixed with GATSBY_ is injected into the client-side bundle. Attackers look for .env files, source maps, and internal documentation left in the build artifact to map the attack surface.

The Vulnerable Pattern

// .env.production - LEAKING SECRETS
GATSBY_FIREBASE_API_KEY=xyz123
GATSBY_STRIPE_SECRET_KEY=sk_live_51M... // CRITICAL: Secret key exposed to frontend
// gatsby-config.js
module.exports = {
plugins: [
// Source maps enabled in production leak source code structure
{ resolve: ‘gatsby-plugin-webpack-bundle-analyser-v2’ }
]
};
// Filesystem: /static/internal_api_docs.pdf (Accessible at /internal_api_docs.pdf)

The Secure Implementation

To fix improper asset management in Gatsby: 1. Strict Prefixing: Only use the GATSBY_ prefix for variables intended for the browser. Secrets like API keys or DB credentials must lack this prefix so they are only available during the build process or in Gatsby Functions. 2. Source Map Deactivation: Use gatsby-node.js to explicitly disable 'devtool' in production builds to prevent code reconstruction via the browser debugger. 3. Static Folder Audit: Never place sensitive PDFs, JSON configs, or backups in the /static folder. 4. Build Artifact Inspection: Use a post-build script to grep the /public directory for sensitive strings or patterns before deployment.

// .env.production - PROTECTING SECRETS
GATSBY_FIREBASE_API_KEY=xyz123 # Public key is fine
STRIPE_SECRET_KEY=sk_live_51M... # No GATSBY_ prefix: stays on build server
// gatsby-node.js - DISABLING SOURCE MAPS
exports.onCreateWebpackConfig = ({ actions, stage }) => {
if (stage === ‘build-javascript’) {
actions.setWebpackConfig({
devtool: false,
});
}
};
// .gitignore
.env*
public/
static/internal/* # Restrict sensitive directories