Modules réservés au serveur

Tel un ami de confiance, SvelteKit sait garder vos secrets. Lorsque vous écrivez votre backend et votre frontend dans le même projet, il est très facile d’accidentellement importer des données sensibles dans votre code front-end (des variables d’environnement contenant des clés d’API, par exemple). SvelteKit fournit un moyen de vous protéger contre ça : les modules réservés au serveur.

Variables d’environnement privées

Les modules $env/static/private et $env/dynamic/private peuvent être uniquement importés dans des modules réservés au serveur, comme hooks.server.js ou +page.server.js.

Utilitaires réservés au serveur

Le module $app/server, qui contient une fonction read permettant de lire des assets sur le système de fichiers, peuvent également uniquement être importés par du code qui s’exécute sur le serveur.

Vos modules

Vous pouvez créer vos propres modules réservés au serveur de deux manières :

• ajouter .server au nom de fichier, par ex. secrets.server.js
• placer vos fichiers dans le dossier $lib/server, par ex $lib/server/secrets.js

Comment ça fonctionne

À chaque fois que du code exposé au public importe du code réservé au serveur (directement ou indirectement)...

export const atlantisCoordinates = [/* censuré */];

export { export atlantisCoordinatesatlantisCoordinates } from '$lib/server/secrets.js';

export const const add: (a: any, b: any) => anyadd = (a, b) => a: anya + b: anyb;

<script>
	import { add } from './utils.js';
</script>

... SvelteKit va produire une erreur :

Cannot import $lib/server/secrets.js into public-facing code:
- src/routes/+page.svelte
	- src/routes/utils.js
		- $lib/server/secrets.js

Même si le code exposé au public — src/routes/+page.svelte — n’utilise que l’export add et non l’export secret atlantisCoordinates, le code secret pourrait se retrouver dans du JavaScript que le navigateur télécharge, ce qui implique que toute la chaîne d’import est considérée non sécurisée.

Cette fonctionnalité fonctionne également avec les imports dynamiques, même ceux interpolés comme await import(`./${foo}.js`), avec un petit inconvénient : pendant le développement, s’il y a deux imports dynamiques ou plus entre le code exposé au public et le module réservé au serveur, l’import illégal ne sera pas détecté la première fois que le code est chargé.

Les frameworks de test unitaire comme Vitest ne font pas la différence entre le code réservé au serveur et celui exposé au public. Pour cette raison, la détection d’imports illégaux est désactivée lors de l’exécution des tests, comme déterminé par process.env.TEST === 'true'.

Plus de lecture

• Tutoriel : Variables d’environnement