Коли ви впроваджуєте відполірований інтерфейс для відображення PDF, PPT або рахунків, зазвичай зосереджуєтесь на естетиці, адаптивності та швидкості завантаження. Однак часто ігнорується те, як документи переміщуються від вашого сервера до браузера користувача. Одна помилка може перетворити інакше надійний додаток у вектор витоку даних.
У цьому посібнику ми розглянемо сем функцій, орієнтованих на безпеку, які варто вбудовувати — одразу «з коробки» — при інтеграції переглядача документів, орієнтованого на конфіденційність. Чек‑лист написаний для фронтенд‑інженерів, які хочуть зміцнити свої вбудовування без зайвої складності.
1. Кінцеве‑кінцеве шифрування потоку документу
Чому це важливо
Навіть якщо ви подаєте файли через HTTPS, необроблений документ може бути перехоплений компрометованим розширенням браузера або зловмисним скриптом, який читає відповідь до того, як вона потрапить у переглядач.
Як реалізувати
| Крок | Дія |
|---|---|
| Шифрування на боці сервера | Шифруйте файл (AES‑256‑GCM — надійний вибір) перед його зберіганням або трансляцією. |
| Безпека транспорту | Передавайте зашифрований блок даних через TLS 1.3. |
| Розшифрування на боці клієнта | Запустіть Web Worker, який отримує зашифрований потік, розшифровує його в пам’яті та передає відкритий текст безпосередньо на канвас переглядача. |
| Ніколи не розкривайте ключ | Тримайте ключ розшифрування у короткоживучому токені, згенерованому сервером (див. функцію #4). |
До моменту, коли переглядач відображає документ, він ніколи не був відкритим у вигляді простого тексту в мережі чи в головному потоці.
2. Белі списки політики безпеки вмісту (CSP)
Ризик
Ліберальна CSP дозволяє зловмиснику інжектувати шкідливі скрипти або завантажувати підозрілі ресурси, які можуть зчитати дані канваса переглядача.
Ключові моменти
- ‘unsafe‑inline’ та ‘unsafe‑eval’ заборонені для скриптів.
- Дозволено лише CDN переглядача (або власний пакет) для JavaScript.
- Фрейми обмежені довіреним доменом переглядача.
Тісна CSP значно зменшує поверхню атаки сторінки, що хостить вбудовування.
3. Ізоляція за принципом того ж походження через пісочницю iframe
Чому пісочниця?
Навіть при наявності CSP зламанна сторінка може спробувати проникнути у DOM переглядача. Ізольований <iframe> створює клітку безпеки, яку хост‑сторінка не може порушити без явного дозволу.
Прапорці пісочниці, які слід уникати
allow-top-navigation— запобігає захопленню верхнього вікна переглядачем.allow-popups— блокує несподівані спливаючі вікна, які можуть бути використані для фішингу.
Якщо переглядач потребує взаємодії з батьківською сторінкою (наприклад, синхронізація UI), використовуйте postMessage з явною перевіркою походження.
4. Токен‑базований контроль доступу
Проблема з прямими URL‑адресами
Публічні, статичні URL‑адреси дозволяють будь‑якому, хто має посилання, завантажувати файл назавжди.
Токен підписується на боці сервера, і будь‑яке його підроблення робить запит недійсним, а переглядач відмовляє у завантаженні.
5. Водяні знаки та динамічні накладки
Призначення
Динамічний, клієнтський водяний знак додає шар відповідальності без зміни оригінального файлу.
Поради щодо впровадження
- Відображайте водяний знак на canvas overlay, який розташований над сторінками PDF.
- Використовуйте електронну пошту сесії або випадковий UUID, щоб кожен екземпляр переглядача був унікальним.
- Перемикайте накладення простим прапорцем, щоб мінімізувати навантаження на продуктивність.
Якщо з’явиться викрадений документ, вбудований ідентифікатор одразу вказує на джерело.
6. Обмеження завантаження та друку
Стандартні можливості браузера
Більшість браузерів показують контекстне меню правою кнопкою, яке дозволяє зберегти канвас як зображення, фактично експортувавши сторінку.
Що може і чого не може переглядач
SDK переглядача може приховати дії експорту з панелі інструментів, а каталог функцій Doconut перераховує можливості друку в браузері та експорту PDF серед налаштувань, які ви вирішуєте надати. Перевіряйте назви параметрів у документації конкретної збірки, а не в статтях, включаючи цю; ключі конфігурації змінюються між версіями.
Більш важливим є те, що жодне налаштування панелі інструментів не замінює контроль доступу. Сервер все одно повинен авторизовувати кожен запит на сторінку, мініатюру, експорт, завантаження та друк, оскільки ці кінцеві точки можна викликати безпосередньо. І коли пікселі вже на екрані, скріншоти, камери та інструменти доступності існують; переглядач, який обіцяє інше, продає те, чого не може надати.
7. Журнальне логування та події
Цінність видимості
Навіть найзахищеніший переглядач може бути зловживаним. Журнальне фіксування того, хто відкрив який документ, коли і які дії виконав, створює судово‑доказову слідку.
З реальними журналами в режимі реального часу ви можете виявляти аномальні патерни — наприклад, один користувач відкриває десятки конфіденційних PDF за секунди — і ініціювати сповіщення або відкликання доступу.
Висновок
Вбудовування переглядача документів — це відповідальність за безпеку, а не лише за UI. Шифрування потоку документу, сувора Content‑Security‑Policy, ізольована iframe sandbox, токен‑базований доступ, динамічні водяні знаки, обмеження експорту, розглянуті як UX, а не як захист, та журнальне аудиту — це те, що розрізняє вбудовування, яке можна захистити, і те, яке ні.
Дві з цих семи функцій залишаються вашими незалежно від вибраного переглядача: авторизація та аудит. Жоден компонент не може приймати це рішення за вашу арену.
Готові створювати вбудовування?
- Починайте з документації постачальника для встановленої версії. Для Doconut це doconut.com — пакети, посібники з налаштування та приклади. Копіювання ключів конфігурації зі статей призводить до поломок при оновленні.
- Додайте сем‑пунктовий чек‑лист у шаблон pull‑request, щоб перевірка безпеки відбувалася до злиття, а не після інциденту.
- Спершу тестуйте негативні випадки: ідентифікатор документа іншого орендаря, прострочену сесію, прямий запит до сторінки або кінцевої точки експорту. Саме ці тести виявляють реальні уразливості.