Змінні оточення Vite відкриті: префікс означає опублікувати це

Хтось відкрив ваш застосунок на Lovable, натиснув F12 і знайшов у коді значення, яке ви точно поклали у файл .env. Або ви попросили в білдера нову функцію, він написав рядок, що починається з VITE_, а щось, прочитане вами відтоді, каже, що саме через цей префікс витікають ключі. У назві файлу є .env, і кожен посібник каже ніколи ним не ділитися. Змінні оточення Vite, відкриті кожному відвідувачу, звучать як помилка у Vite.

Ось та частина, яку посібник за посібником пояснює неправильно: ніщо не провалило спробу сховати це значення. VITE_ і NEXT_PUBLIC_ є інструкцією для вашого інструмента збірки, і ця інструкція звучить так: поклади значення в застосунок, який завантажує кожен відвідувач. Інструмент прочитав мітку і зробив те, що на ній написано.

Збірка пакує ваш застосунок у коробку, і кожен відвідувач отримує копію цієї коробки. Префікс є міткою на одному значенні, яка каже: запакуй і це. Решта цієї статті про те, для яких значень ця мітка правильна, чому ШІ чіпляє її на неправильні, і як побачити, що лежить у вашій власній коробці.

Чи відкриті змінні оточення Vite для відвідувачів?

Ті, що починаються з VITE_, так, і саме для цього префікс існує.

Vite, інструмент збірки за більшістю застосунків на Lovable і Bolt, читає ваш файл .env під час кожної збірки. Змінна з назвою VITE_SUPABASE_URL копіюється в бандл, стиснутий файл JavaScript, який завантажує кожен відвідувач, і там ваш код читає її як import.meta.env.VITE_SUPABASE_URL. Змінна з назвою DB_PASSWORD, без префікса, приходить у браузер порожньою. Власна документація Vite каже, що значення з префіксом під час збірки вбудовуються у ваш вихідний код і не повинні містити ключів API.

Next.js, на якому будує v0, має те саме правило під іншою назвою: NEXT_PUBLIC_. Його документація описує значення як inlined, жорстко вписаний рядок, записаний у браузерний бандл під час збірки. Expo використовує EXPO_PUBLIC_ і попереджає тими самими словами. Старіші проєкти Create React App використовують REACT_APP_. Кожен префікс каже своєму інструменту збірки те саме: це йде в коробку.

Чому файл .env здається приватним, хоч він не такий

Бо звичка тримати ключ у файлі .env прийшла із серверів, де вона працює.

На сервері файл і код, який його читає, лежать на машині, яку контролюєте ви. Відвідувач отримує від цієї машини відповідь і ніколи не бачить файлу. Винести ключ із коду у файл, який сервер читає під час запуску, там є доброю практикою, і саме там написано кожен посібник, який каже «поклади це в .env».

У вашого файлу .env є два читачі, а посібники розповідають про одного. Перший читач: будь-хто, хто може бачити ваш проєкт, тобто співавтор, публічний репозиторій на GitHub, перегляд файлів у самому білдері. Запис у .gitignore, тобто у списку файлів, які git пропускає, тримає .env подалі від цього читача. Другий читач: збірка, яка відкриває файл щоразу, коли ви публікуєте, і копіює звідти все, що має префікс. .gitignore їй нічого не каже.

Тож «мій .env у gitignore» є правдою, і це відповідь на інше запитання. Файл лишився поза вашим репозиторієм. Значення з префіксом усе одно потрапили в застосунок, бо саме цей шлях префікс і відкриває, а в проєкті на Lovable, Bolt чи v0 більшість коду, який ви редагували, працює в браузері, де немає сервера, за яким файл міг би залишитися.

Чому ШІ потягнувся до префікса

Бо саме так змушують значення працювати в коді браузера, а модель гадки не має, скільки це значення коштує.

Ви попросили мапу або чат, який відповідає на запитання про ваш продукт. Код, який білдер для цього написав, працює в браузері відвідувача, а код браузера, що читає process.env.OPENAI_API_KEY, не отримує нічого. Спосіб доставити значення: префікс. Білдер перейменовує змінну на VITE_OPENAI_API_KEY, функція працює в попередньому перегляді, і ніде не з’являється жодної помилки, бо з боку інструмента збірки нічого не пішло не так.

Префікс не судить. Це та сама інструкція і для ключа Google Maps, який має бути публічним після обмеження, і для секретного ключа Stripe, який може повернути гроші кожному вашому клієнту. Людина, яка знала б, що другий списує гроші з вашої картки, зупинилася б. Модель знає, що функція не працювала, доки цього рядка не було, а потім запрацювала.

Саме тому це трапляється в застосунках, власники яких зробили все, що їм казали. Значення винесли з коду, тримали у .env, файл був у gitignore, а застосунок усе одно його віддає, бо єдиний крок, який його публікує, виглядає як крок, який змушує його працювати.

Які значення можуть стояти за префіксом

Адреса і публічний ключ. Усе, що витрачає гроші або ігнорує правила вашої бази даних, ні.

Якщо у вашому застосунку є VITE_SUPABASE_URL і поруч публічний ключ, це та пара, яку Supabase задумав для браузера, і наше сканування позначає її як доречну. Адреса і публічний ключ і є причиною, чому префікс існує.

Перевірка для всього іншого: чи заперечували б ви, якби це значення надрукували на вашій головній сторінці. Префікс кладе його на один клік далі, у файл замість сторінки, і файл має кожен, хто його хоче. Як відрізнити ці дві родини, за префіксом, а в старішому ключі Supabase за роллю всередині, є окремою статтею.

Що 30 998 застосунків віддавали за префіксом

Здебільшого ключі Google API. 52 застосунки віддавали ключ, який витрачає гроші або читає все.

У серпні 2026 року ми запустили ті самі дев’ять перевірок на 30 998 живих vibe-coded застосунках. 1 332 з них, тобто 4%, віддавали щось схоже на ключ у коді, який завантажує кожен відвідувач. 1 142 з них були ключами Google API, яким зазвичай потрібне обмеження, задане в Google Cloud, а не ротація. 204 віддавали випадкове на вигляд значення поруч із назвою на кшталт secret чи password, яке може бути справжніми обліковими даними, а може й ні.

Дорогі випадки були рідкісними. 33 застосунки віддавали ключ OpenAI, 9 ключ доступу AWS, 5 ключ Anthropic, 3 секретний ключ Stripe і 3 ключ service_role від Supabase: 52 застосунки загалом, бо один із них ніс два. Тож значення за префіксом зазвичай є ключем Google, і виправлення для нього є налаштуванням. Рідкісний випадок і є тим, де живе шкода, а скільки коштує витеклий ключ OpenAI, розповідає стаття саме про нього.

Як перевірити, що віддає ваш власний застосунок

Відкрийте живий застосунок, натисніть F12 і пошукайте значення в кожному завантаженому файлі.

1. Відкрийте свій опублікований застосунок у браузері за його справжньою адресою. Попередній перегляд у білдері є іншою збіркою і може відставати на версію.
2. Натисніть F12, щоб відкрити інструменти розробника, і виберіть вкладку Sources.
3. Натисніть Ctrl+Shift+F або Cmd+Option+F на Mac. Це відкриє пошук по кожному файлу, який завантажила сторінка.
4. Вставте перші приблизно десять символів значення, яке вас непокоїть, і більше нікуди його не вставляйте.

Збіг означає, що значення лежить у коробці, яку отримує кожен відвідувач. Шукайте значення, а не назву: збірка зазвичай замінює import.meta.env.VITE_OPENAI_API_KEY на саме значення, тож пошук за VITE_ може повернутися порожнім, тоді як кожне значення за ним на місці.

Якщо ви не хочете проходити свій застосунок значення за значенням, наше безкоштовне сканування читає ваш живий сайт ззовні, усі дев’ять перевірок, приблизно за 20 секунд і без облікового запису. Воно називає кожен знайдений ключ за типом, каже, які з них доречні в браузері, і пише «Не вдалося перевірити» для всього, на що не змогло відповісти, замість галочки: проскануйте свій застосунок.

Куди натомість іде справжній секрет

На машину, з якої ваші відвідувачі ніколи нічого не завантажують. У проєкті Supabase це Edge Function, невеликий шматок серверного коду, який Supabase запускає за вас; у застосунку на Next.js це серверний маршрут; у застосунку на Replit це серверна половина.

Форма всюди та сама. Ваш код у браузері просить вашу функцію зробити роботу. Функція тримає ключ, робить виклик до OpenAI чи Stripe і повертає відповідь. Ключ лишається на машині, а відвідувач отримує результат. Стаття про OpenAI малює це як один об’єкт, що зсувається на одну клітинку праворуч, і в цьому вся зміна.

Дві речі скажуть вам, що білдер зробив те, про що ви просили. Змінна втратила префікс, тож тепер це OPENAI_API_KEY, і живе вона у власних секретах функції, заданих у панелі Supabase у розділі Edge Functions, а в .env застосунку нічого немає. І файл, який її читає, лежить у supabase/functions/ або app/api/, там, куди збірка ніколи не пакує, а не в src/.

Один порядок має значення, і його легко переплутати. Якщо секретний ключ уже пішов у бандл за префіксом, перенесення нічого не дасть для вже завантажених копій. Спершу зробіть ротацію в провайдера, потім переносьте роботу. Чи спершу ротація, чи спершу закрити витік, залежить від того, чи копія вже публічна, а щойно вона побувала в опублікованому бандлі, вона публічна.

У проєкті на Replit той самий поділ має власну назву, Secrets, і що інструмент Secrets покриває, а що ні, є окремою статтею.

Що робити просто зараз

Кожна публікація пакує нову коробку. Наступна функція, яку ви попросите, є ще однією нагодою для значення отримати префікс, і ніщо між білдером та інтернетом не читає бандл на виході. Сканування минулого місяця прочитало бандл минулого місяця.

Reeve Monitor читає бандл за вас. Він щогодини повторює всі дев’ять перевірок на щонайбільше трьох застосунках, повідомляє вас, коли результат змінюється, стежить за доступністю кожні 60 секунд і надсилає щомісячний звіт. Ключ, який потрапляє в бандл із публікацією у вівторок, є в повторному скануванні тієї самої години, згадали ви подивитися чи ні. Коштує $12 на місяць за прайсом, із сімома безкоштовними днями до першого списання; сторінка цін іноді нижча за цифру тут і ніколи не вища.

Якщо вам зручніше пройти це списком, 10-хвилинний чекліст безпеки покриває це і решту речей, які варто вимкнути в щойно запущеному застосунку.