$env/static/private can be imported in client modules

[aloker]

Describe the bug

If I understood correctly, mechanisms should be in place that prevent $env/static/private to be imported in client modules (like routes). However, this does not seem to be the case. I can import from $env/static/private and the variables get transpiled into the client side javascript modules.

My excuses if this feature is not yet supposed to work.

Reproduction

A simple repo showing the issue:
https://github.com/aloker/sveltekit-private-env

https://github.com/aloker/sveltekit-private-env/blob/main/src/routes/index.svelte

Logs

No response

System Info

System:
    OS: Windows 10 10.0.19043
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz   
    Memory: 8.81 GB / 31.81 GB
  Binaries:
    Node: 16.15.1 - c:\tools\node\node.EXE
    Yarn: 1.22.19 - c:\tools\node\yarn.CMD
    npm: 8.13.2 - c:\tools\node\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (103.0.1264.71)
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.64 
    @sveltejs/kit: next => 1.0.0-next.396 
    svelte: ^3.44.0 => 3.49.0 
    vite: ^3.0.0 => 3.0.3

Severity

serious, but I can work around it

Additional Information

No response

[elliott-with-the-longest-name-on-github]

That's odd. I cloned your repo. When running dev and visiting the root, I get this:

When running build, the same error prevents the build from completing. Can you explain exactly what you're doing? Maybe it's something unusual we didn't think about that's bypassing the error mechanism somehow.

One thing to be aware of is that there's no way for the dev process to perform the module analysis it needs to create this error prior to visiting an "infected" page, so running pnpm dev will work fine, but you should receive a big ol' error page if you actually visit /.

[aloker]

I'll make sure to double check again.Could it be a Windows thing?

[elliott-with-the-longest-name-on-github]

I'll make sure to double check again.Could it be a Windows thing?

Ah, yeah, hadn't thought of that. If there's some funkiness with how the Windows paths are represented as module IDs, we could miss it.

[elliott-with-the-longest-name-on-github]

One of the other maintainers suggested adding this to all of your files:

if (os.windows) {
  throw new Error('Use a better OS');
}

😉

In all seriousness, I'm going to try to boot up a Windows VM and see if I can replicate it.

[elliott-with-the-longest-name-on-github]

@aloker

The linked PR should fix this. If you get the chance, feel free to check out that branch and verify that it fails on your machine.

[phenomen]

I have the same error on Netlify w/ Netlify adapter

[elliott-with-the-longest-name-on-github]

@phenomen

This is intended. You're trying to import a module into client-side code that imports a private environment variable. This will cause that private variable to be exposed to the client.

[phenomen]

@tcc-sejohnson
So how am I supposed to use it? Here is my current setup that works locally but fails in production:

SUPABASE_URL/KEY are in .env that is not uploaded to the server.
NETLIFY_SUPABASE_URL/KEY are environmental variables I put into build options on Netlify.

db.js

import { createClient } from '@supabase/supabase-js';
import { SUPABASE_URL, SUPABASE_KEY } from '$env/static/private';

const supabaseURL = SUPABASE_URL || process.env.NETLIFY_SUPABASE_URL;
const supabaseKey = SUPABASE_KEY || process.env.NETLIFY_SUPABASE_KEY;

const supabase = createClient(supabaseURL, supabaseKey);

export default supabase;

[elliott-with-the-longest-name-on-github]

@phenomen

I'm not intimately familiar with Supabase, but given that you're using a secret key to instantiate the Supabase client, it is NOT safe to expose to the client/browser. You need to relegate use of that client to the server (hooks and endpoints). Importing it into Svelte files would result in you exposing your API key.

[philip-weber]

@phenomen I think you refer to the SUPABASE_ANON_KEY when you write SUPABASE_KEY, right? The SUPABASE_ANON_KEY and the SUPABASE_URL are safe to be exposed to the client. At least if you are using the Row Level Security features from Supabase. So you could import them from $env/static/public and would not get the build error. I think you could even remove the NETLIFY_* versions and just name them the same in your local .env file and the Netlify config. This works for me on Cloudflare Page but I am not that familiar with Netlify. So I could be wrong here. Could be worth a try.

[aloker]

@aloker

The linked PR should fix this. If you get the chance, feel free to check out that branch and verify that it fails on your machine.

I tested it locally and I can confirm that it now correctly fails. Thanks for the quick fix.