Посилила захист застосунку CSP на основі nonce

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

Завдання. Платформу потрібно було захистити на кожному рівні — фронтенд, API, база даних, — так, щоб безпеку забезпечував сервер незалежно від того, що саме дозволяв інтерфейс.

Дія. На фронтенді проміжний шар proxy в Next.js — proxy.ts — встановлює Content‑Security‑Policy з nonce для кожного запиту та strict‑dynamic, а також HSTS і SameSite cookies, тож браузер жорстко обмежено в тому, що він виконає й надішле. На рівні API працюють обмеження частоти запитів, CORS, ліміти на розмір запиту, валідація вхідних даних ще до того, як щось потрапить у базу даних, і журналювання подій, важливих для безпеки. У базі даних API входить під роллю з мінімальними привілеями, яка може лише виконувати (EXECUTE) функції застосунку, самі функції працюють як SECURITY DEFINER, а все параметризовано. А права доступу — тариф, роль, організацію, прив’язку до судна — сервер повторно перевіряє під час кожного запиту, а обмеження на фронтенді вважаються суто питанням UX. Ці обмеження визначають, що видно; сервер визначає, що дозволено робити.

Результат. Безпека не залежить від того, чи поводиться UI як слід. Захист побудовано шарами так, щоб подолання одного з них не відкривало шляху крізь решту, а вся система спирається на припущення, що клієнтові довіряти не можна, — і це правильне припущення для даних, які люди довіряють платформі, розраховуючи на конфіденційність.