Fix Improper Assets Management in SvelteKit

Improper asset management in SvelteKit is a critical oversight where developers treat the 'static/' directory as a general-purpose storage bin. In SvelteKit, anything inside 'static/' is served directly by the web server, bypassing all middleware, hooks, and authentication logic. If you leak a database backup, a '.env' copy, or internal documentation there, it's game over. Attackers use automated scanners to find these 'forgotten' assets and pivot into your infrastructure.

The Vulnerable Pattern

// Project Structure:
// /static/config.json  <-- VULNERABLE: Exposed to the public
// /static/.env.backup <-- VULNERABLE: Exposed to the public
// src/routes/settings/+page.svelte

The Secure Implementation

To fix improper asset management, you must enforce a strict boundary between public assets and server-side data. First, purge the 'static/' folder of anything that isn't a public image, font, or global CSS file. Second, leverage SvelteKit's '$env/static/private' or '$env/dynamic/private' modules; these are designed to prevent secrets from ever being bundled into the client-side code—if you attempt to import them into a client-side component, the compiler will throw an error. Finally, always route sensitive data requests through '+server.js' or '+page.server.js' files where you can perform session validation and access control before data egress.

// 1. Move secrets to .env (outside of static/)
// .env -> PRIVATE_API_KEY=secret_value_here
// 2. Access secrets only via server-side modules
// src/lib/server/secrets.js
import { PRIVATE_API_KEY } from ‘$env/static/private’;
export const getInternalConfig = () => ({ key: PRIVATE_API_KEY });
// 3. Use a +server.js endpoint with proper authorization
// src/routes/api/config/+server.js
import { error, json } from ‘@sveltejs/kit’;
import { getInternalConfig } from ‘$lib/server/secrets’;
export function GET({ locals }) {
if (!locals.user?.isAdmin) throw error(403, ‘Unauthorized’);
return json(getInternalConfig());
}