هنگامی که یک رابط کاربری صیقلی برای نمایش PDFها، PPTها یا فاکتورها ارائه می‌دهید، معمولاً بر زیبایی، واکنش‌پذیری و زمان بارگذاری تمرکز می‌کنید. اما چیزی که اغلب نادیده گرفته می‌شود، چگونگی انتقال اسناد از سرور شما به مرورگر کاربر است. یک گام اشتباه می‌تواند یک برنامهٔ محکم را به یک مسیر نشت داده تبدیل کند.
در این راهنما ما هفت قابلیت متمرکز بر امنیت را که باید بلافاصله هنگام یکپارچه‌سازی یک نمایشگر سند با تمرکز بر حریم خصوصی تعبیه کنید، مرور می‌کنیم. این چک‌لیست برای مهندسان فرانت‌اندی نوشته شده است که می‌خواهند ادغام‌های خود را بدون افزودن پیچیدگی‌های غیرضروری تقویت کنند.
1. رمزنگاری انتها به انتهای جریان سند
چرا مهم است
حتی اگر فایل‌ها را از طریق HTTPS سرو کنید، سند خام می‌تواند توسط یک افزونه مرورگر مخدوش یا اسکریپت مخرب که پاسخ را پیش از رسیدن به نمایشگر می‌خواند، رهگیری شود.
چگونه پیاده‌سازی شود
| مرحله | عمل |
|---|---|
| رمزنگاری سمت سرور | فایل را (AES‑256‑GCM یک گزینه مناسب است) قبل از ذخیره یا استریم کردن رمزنگاری کنید. |
| امنیت انتقال | بلاب رمزنگاری شده را از طریق TLS 1.3 تحویل دهید. |
| رمزگشایی سمت کلاینت | یک Web Worker راه‌اندازی کنید که جریان رمزنگاری‌شده را دریافت کند، در حافظه رمزگشایی کند و متن واضح را مستقیماً به بوم (canvas) نمایشگر بدهد. |
| هرگز کلید را فاش نکنید | کلید رمزگشایی را در یک توکن کوتاه‌مدت تولید شده توسط سرور نگه دارید (به ویژگی #4 مراجعه کنید). |
تا زمانی که نمایشگر رندر می‌شود، سند هرگز به صورت متن واضح روی شبکه یا در نخ اصلی در معرض نمایش قرار نمی‌گیرد.
2. فهرست سفید Content‑Security‑Policy (CSP)
ریسک
یک CSP سست به مهاجم اجازه می‌دهد اسکریپت‌های مخرب را تزریق کند یا منابع مخربی را بارگذاری کند که می‌توانند داده‌های بوم نمایشگر را بخوانند.
نکات کلیدی
- ‘unsafe‑inline’ و ‘unsafe‑eval’ برای اسکریپت‌ها ممنوع هستند.
- فقط CDN نمایشگر (یا بسته میزبانی‌شده) مجاز به سرو کردن جاوااسکریپت است.
- فریم‌ها به دامنه معتبر نمایشگر محدود می‌شوند.
یک CSP سفت و سخت به‌طرز چشمگیری سطح حمله صفحه‌ای که embed را میزبانی می‌کند، کاهش می‌دهد.
3. جداسازی هم‌مبدأ از طریق iframe Sandbox
چرا Sandbox؟
حتی با CSP، یک صفحه مخدوش می‌تواند سعی کند به DOM نمایشگر دسترسی پیدا کند. یک <iframe> ایزوله یک قفس امنیتی ایجاد می‌کند که صفحه میزبان بدون اجازه صریح نمی‌تواند آن را بشکند.
پرچم‌های Sandbox که باید اجتناب شود
allow-top-navigation– جلوگیری از ربودن پنجره سطح بالا توسط نمایشگر.allow-popups– مسدود کردن پنجره‌های پاپ‑آپ غیرمنتظره که می‌توانند برای فیشینگ استفاده شوند.
اگر نمایشگر نیاز به ارتباط با صفحه والد داشته باشد (مثلاً برای همگام‌سازی UI)، از postMessage با بررسی صریح origin استفاده کنید.
4. کنترل دسترسی مبتنی بر توکن
مشکل URLهای مستقیم
URLهای عمومی و ثابت به هر کسی که لینک را داشته باشد اجازه می‌دهد فایل را برای همیشه دانلود کند.
از آنجا که توکن به‌صورت سرور‑ساید امضا می‌شود، هر دستکاری‌ای درخواست را نامعتبر می‌کند و نمایشگر از بارگذاری خودداری می‌کند.
5. واترمارک‌گذاری و لایه‌های پویا
هدف
یک واترمارک پویا در سمت کلاینت لایه‌ای از مسئولیت‌پذیری اضافه می‌کند بدون اینکه فایل اصلی تغییر یابد.
نکات پیاده‌سازی
- واترمارک را بر روی یک canvas overlay که بالای صفحات PDF قرار دارد، رندر کنید.
- از ایمیل جلسه یا یک UUID تصادفی استفاده کنید تا هر نمونه نمایشگر منحصر به فرد باشد.
- لایه را با یک پرچم ساده فعال/غیرفعال کنید تا بار عملکردی به حداقل برسد.
اگر سندی نشت کند، شناسهٔ جاسازی‌شده مستقیماً به منبع اشاره می‌کند.
6. محدودیت‌های دانلود و چاپ
پیش‌فرض‌های مرورگر
اکثر مرورگرها منوی کلیک‑راست را نشان می‌دهند که می‌تواند بوم را به‌عنوان تصویر ذخیره کند و به‌طور مؤثری صفحه را صادر کند.
آنچه یک نمایشگر می‌تواند و نمی‌تواند انجام دهد
یک SDK نمایشگر سند می‌تواند اقدامات صادرات را از نوار ابزار مخفی کند، و فهرست ویژگی‌های Doconut مرورگر چاپ و صادرات PDF را در میان قابلیت‌هایی که تصمیم می‌گیرید ارائه دهید، فهرست می‌کند. نام گزینه‌ها را در مقابل مستندات نسخه‌ای که نصب می‌کنید بررسی کنید نه در مقابل هر مقاله‌ای، از جمله این مقاله: کلیدهای پیکربندی بین نسخه‌ها تغییر می‌کنند.
بخش مهم‌تر این است که هیچ تنظیمات نوار ابزاری نمی‌تواند این نکته را پوشش دهد. مخفی کردن یک دکمه یک انتخاب کاری است، نه یک کنترل دسترسی. سرور باید همچنان هر صفحه، تصویر بندانگشتی، صادرات، دانلود و درخواست چاپ را به‌صورت مستقل مجوزدهی کند، زیرا این انتهاها می‌توانند مستقیماً فراخوانی شوند. و وقتی پیکسل‌ها روی صفحه نمایش هستند، اسکرین‌شات، دوربین‌ها و ابزارهای دسترس‌پذیری وجود دارند؛ یک نمایشگر که خلاف این را وعده می‌دهد، در حال فروش چیزی است که نمی‌تواند تحویل دهد.
7. ثبت لاگ حسابرسی و هوک‌های رویداد
ارزش دیداری
حتی امن‌ترین نمایشگر می‌تواند سوءاستفاده شود. ثبت لاگ اینکه چه کسی چه سندی را کی باز کرده و چه اقداماتی انجام داده است، یک ردپای قانونی ایجاد می‌کند.
با لاگ‌های زمان‑واقعی می‌توانید الگوهای غیرعادی—مانند یک کاربر که در چند ثانیه ده‌ها PDF محرمانه را باز می‌کند—تشخیص داده و هشدار یا لغو دسترسی‌ها را فعال کنید.
نتیجه‌گیری
ادغام یک نمایشگر سند یک مسئولیت امنیتی است، نه فقط یک مسئولیت UI. رمزنگاری جریان سند، یک Content‑Security‑Policy سخت، یک iframe sandbox ایزوله، کنترل دسترسی مبتنی بر توکن، واترمارک‌های پویا، محدودیت‌های صادرات که به‌عنوان UX نه به‌عنوان حفاظت در نظر گرفته می‌شوند، و ثبت لاگ حسابرسی آنچه یک embed قابل دفاع را از یک embed غیرقابل دفاع جدا می‌کند.
دو تا از این هفت ویژگی، صرف‌نظر از اینکه کدام نمایشگر را انتخاب کنید، همواره متعلق به شما هستند: احراز هویت و حسابرسی. هیچ مؤلفه‌ای نمی‌تواند این تصمیم را به جای شما بگیرد.
آماده ساختن embed هستید؟
- از مستندات رسمی فروشنده برای نسخه‌ای که نصب می‌کنید شروع کنید. برای Doconut، این آدرس doconut.com است — بسته‌ها، راهنمای نصب و نمونه‌ها. کپی کردن کلیدهای پیکربندی از مقالات باعث می‌شود یکپارچه‌سازی‌ها در هنگام ارتقا شکسته شوند.
- چک‌لیست هفت‌نقطه‌ای را در قالب pull‑request خود بگذارید تا بازبینی امنیتی قبل از ادغام، نه پس از حادثه، انجام شود.
- اولین موارد منفی را تست کنید: شناسه سند یک مستأجر دیگر، جلسه منقضی‌شده، درخواست مستقیم به یک صفحه یا نقطه انتهایی صادرات. این‌ها تست‌هایی هستند که حفره‌های واقعی را پیدا می‌کنند.