یک چارچوب جامع برای امنیت جاوا اسکریپت را کشف کنید. استراتژی‌های کلیدی برای محافظت از برنامه‌های وب خود در برابر تهدیدات سمت کلاینت مانند XSS، CSRF و سرقت داده را بیاموزید.
چارچوب پیاده‌سازی امنیت وب: یک استراتژی جامع برای حفاظت از جاوا اسکریپت
در اکوسیستم دیجیتال مدرن، جاوا اسکریپت موتور بی‌چون و چرای وب تعاملی است. این زبان همه چیز را، از رابط‌های کاربری پویا در سایت‌های تجارت الکترونیک در توکیو گرفته تا مصورسازی‌های پیچیده داده برای مؤسسات مالی در نیویورک، قدرت می‌بخشد. با این حال، همین فراگیری آن را به هدفی اصلی برای بازیگران مخرب تبدیل کرده است. با تلاش سازمان‌ها در سراسر جهان برای ارائه تجربیات کاربری غنی‌تر، سطح حمله سمت کلاینت گسترش می‌یابد و کسب‌وکارها و مشتریانشان را در معرض خطرات قابل توجهی قرار می‌دهد. رویکرد واکنشی و مبتنی بر وصله (patch) دیگر برای امنیت کافی نیست. آنچه مورد نیاز است، یک چارچوب پیشگیرانه و ساختاریافته برای پیاده‌سازی حفاظت قدرتمند از جاوا اسکریپت است.
این مقاله یک چارچوب جهانی و جامع برای ایمن‌سازی برنامه‌های وب مبتنی بر جاوا اسکریپت شما ارائه می‌دهد. ما فراتر از راه‌حل‌های ساده خواهیم رفت و یک استراتژی لایه‌ای و دفاع در عمق را بررسی خواهیم کرد که به آسیب‌پذیری‌های اصلی موجود در کدهای سمت کلاینت می‌پردازد. چه یک توسعه‌دهنده، یک معمار امنیت یا یک رهبر فناوری باشید، این راهنما شما را به اصول و تکنیک‌های عملی برای ساختن حضوری مقاوم‌تر و امن‌تر در وب مجهز می‌کند.
درک چشم‌انداز تهدیدات سمت کلاینت
قبل از پرداختن به راه‌حل‌ها، درک محیطی که کد ما در آن اجرا می‌شود، حیاتی است. برخلاف کدهای سمت سرور که در یک محیط کنترل‌شده و قابل اعتماد اجرا می‌شوند، جاوا اسکریپت سمت کلاینت در مرورگر کاربر اجرا می‌شود—محیطی که ذاتاً غیرقابل اعتماد است و در معرض متغیرهای بی‌شماری قرار دارد. این تفاوت اساسی، منشأ بسیاری از چالش‌های امنیت وب است.
آسیب‌پذیری‌های کلیدی مرتبط با جاوا اسکریپت
- اسکریپت‌نویسی بین سایتی (XSS): این شاید شناخته‌شده‌ترین آسیب‌پذیری سمت کلاینت باشد. یک مهاجم اسکریپت‌های مخرب را به یک وب‌سایت مورد اعتماد تزریق می‌کند، که سپس توسط مرورگر قربانی اجرا می‌شوند. XSS سه نوع اصلی دارد:
- XSS ذخیره‌شده: اسکریپت مخرب به طور دائم روی سرور هدف ذخیره می‌شود، مثلاً در یک پایگاه داده از طریق یک فیلد نظر یا پروفایل کاربر. هر کاربری که از صفحه آلوده بازدید می‌کند، اسکریپت مخرب را دریافت می‌کند.
- XSS منعکس‌شده: اسکریپت مخرب در یک URL یا دیگر داده‌های درخواست جاسازی می‌شود. هنگامی که سرور این داده‌ها را به مرورگر کاربر بازمی‌گرداند (مثلاً در یک صفحه نتایج جستجو)، اسکریپت اجرا می‌شود.
- XSS مبتنی بر DOM: آسیب‌پذیری کاملاً در کد سمت کلاینت قرار دارد. یک اسکریپت، مدل شیء سند (DOM) را با استفاده از داده‌های ارائه‌شده توسط کاربر به روشی ناامن تغییر می‌دهد، که منجر به اجرای کد بدون اینکه داده‌ها هرگز مرورگر را ترک کنند، می‌شود.
- جعل درخواست بین سایتی (CSRF): در یک حمله CSRF، یک وب‌سایت، ایمیل یا برنامه مخرب باعث می‌شود مرورگر وب کاربر یک عمل ناخواسته را در یک سایت مورد اعتماد که کاربر در آن احراز هویت شده است، انجام دهد. به عنوان مثال، کاربری که روی یک لینک در یک سایت مخرب کلیک می‌کند، می‌تواند ناآگاهانه درخواستی را به وب‌سایت بانکی خود برای انتقال وجه ارسال کند.
- داده‌ربایی (حملات به سبک Magecart): یک تهدید پیچیده که در آن مهاجمان جاوا اسکریپت مخرب را به صفحات پرداخت تجارت الکترونیک یا فرم‌های پرداخت تزریق می‌کنند. این کد به صورت پنهانی اطلاعات حساس مانند جزئیات کارت اعتباری را ضبط (skim) کرده و به سرور تحت کنترل مهاجم ارسال می‌کند. این حملات اغلب از یک اسکریپت شخص ثالث به خطر افتاده نشأت می‌گیرند، که شناسایی آنها را بسیار دشوار می‌سازد.
- ریسک‌های اسکریپت‌های شخص ثالث و حملات زنجیره تأمین: وب مدرن بر پایه اکوسیستم وسیعی از اسکریپت‌های شخص ثالث برای تحلیل، تبلیغات، ویجت‌های پشتیبانی مشتری و موارد دیگر ساخته شده است. در حالی که این خدمات ارزش بسیار زیادی ارائه می‌دهند، ریسک قابل توجهی را نیز به همراه دارند. اگر هر یک از این ارائه‌دهندگان خارجی به خطر بیفتند، اسکریپت مخرب آنها مستقیماً به کاربران شما ارائه می‌شود و اعتماد و مجوزهای کامل وب‌سایت شما را به ارث می‌برد.
- کلیک‌ربایی (Clickjacking): این یک حمله بازآرایی رابط کاربری (UI redressing) است که در آن مهاجم از چندین لایه شفاف یا مات برای فریب دادن کاربر استفاده می‌کند تا او را وادار به کلیک بر روی یک دکمه یا لینک در صفحه‌ای دیگر کند، در حالی که قصد داشته روی صفحه اصلی کلیک کند. این روش می‌تواند برای انجام اقدامات غیرمجاز، افشای اطلاعات محرمانه یا به دست گرفتن کنترل کامپیوتر کاربر استفاده شود.
اصول اصلی یک چارچوب امنیت جاوا اسکریپت
یک استراتژی امنیتی مؤثر بر پایه اصول مستحکم بنا شده است. این مفاهیم راهنما کمک می‌کنند تا اطمینان حاصل شود که اقدامات امنیتی شما منسجم، جامع و سازگار هستند.
- اصل کمترین امتیاز (Least Privilege): هر اسکریپت و مؤلفه باید فقط مجوزهای کاملاً ضروری برای انجام عملکرد قانونی خود را داشته باشد. به عنوان مثال، اسکریپتی که یک نمودار را نمایش می‌دهد نباید به داده‌های فیلدهای فرم دسترسی داشته باشد یا درخواست‌های شبکه به دامنه‌های دلخواه ارسال کند.
- دفاع در عمق (Defense in Depth): اتکا به یک کنترل امنیتی واحد، دستورالعملی برای فاجعه است. یک رویکرد لایه‌ای تضمین می‌کند که اگر یک لایه دفاعی شکست بخورد، لایه‌های دیگر برای کاهش تهدید وجود دارند. به عنوان مثال، حتی با وجود خروجی‌کُدی بی‌نقص برای جلوگیری از XSS، یک خط مشی امنیت محتوای قوی، لایه دوم حیاتی حفاظت را فراهم می‌کند.
- امنیت به طور پیش‌فرض (Secure by Default): امنیت باید یک الزام بنیادی باشد که در چرخه عمر توسعه تعبیه شده است، نه یک فکر ثانویه. این به معنای انتخاب چارچوب‌های امن، پیکربندی خدمات با در نظر گرفتن امنیت و تبدیل مسیر امن به ساده‌ترین مسیر برای توسعه‌دهندگان است.
- اعتماد کن ولی راستی‌آزمایی کن (اعتماد صفر برای اسکریپت‌ها): به هیچ اسکریپتی، به ویژه اسکریپت‌های شخص ثالث، به طور ضمنی اعتماد نکنید. هر اسکریپت باید بررسی شود، رفتار آن درک شود و مجوزهای آن محدود گردد. فعالیت آن را به طور مداوم برای هرگونه نشانه به خطر افتادن، نظارت کنید.
- خودکارسازی و نظارت: نظارت انسانی مستعد خطا است و نمی‌تواند مقیاس‌پذیر باشد. از ابزارهای خودکار برای اسکن آسیب‌پذیری‌ها، اجرای خط‌مشی‌های امنیتی و نظارت بر ناهنجاری‌ها در زمان واقعی استفاده کنید. نظارت مستمر کلید شناسایی و پاسخ به حملات در حین وقوع است.
چارچوب پیاده‌سازی: استراتژی‌ها و کنترل‌های کلیدی
با تثبیت اصول، بیایید کنترل‌های فنی و عملی را که ستون‌های چارچوب امنیت جاوا اسکریپت ما را تشکیل می‌دهند، بررسی کنیم. این استراتژی‌ها باید به صورت لایه‌ای پیاده‌سازی شوند تا یک وضعیت دفاعی قدرتمند ایجاد کنند.
۱. خط مشی امنیت محتوا (CSP): اولین خط دفاعی
خط مشی امنیت محتوا (CSP) یک هدر پاسخ HTTP است که به شما کنترل دقیقی بر روی منابعی که یک عامل کاربری (مرورگر) مجاز به بارگیری برای یک صفحه خاص است، می‌دهد. این یکی از قدرتمندترین ابزارها برای کاهش حملات XSS و داده‌ربایی است.
چگونه کار می‌کند: شما یک لیست سفید (whitelist) از منابع مورد اعتماد برای انواع مختلف محتوا، مانند اسکریپت‌ها، شیوه‌نامه‌ها، تصاویر و فونت‌ها تعریف می‌کنید. اگر صفحه‌ای سعی کند منبعی را از منبعی که در لیست سفید نیست بارگیری کند، مرورگر آن را مسدود خواهد کرد.
مثال هدر CSP:
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-analytics.com; img-src *; style-src 'self' 'unsafe-inline'; report-uri /csp-violation-report-endpoint;
دستورالعمل‌های کلیدی و بهترین شیوه‌ها:
default-src 'self': این یک نقطه شروع عالی است. این دستورالعمل همه منابع را به بارگیری فقط از همان مبدأ سند محدود می‌کند.script-src: حیاتی‌ترین دستورالعمل. این دستور منابع معتبر برای جاوا اسکریپت را تعریف می‌کند. به هر قیمتی از'unsafe-inline'و'unsafe-eval'اجتناب کنید، زیرا آنها بخش بزرگی از هدف CSP را از بین می‌برند. برای اسکریپت‌های درون‌خطی، از یک nonce (یک مقدار تصادفی و یک‌بار مصرف) یا یک هش استفاده کنید.connect-src: کنترل می‌کند که صفحه به کدام مبدأها می‌تواند با استفاده از APIهایی مانندfetch()یاXMLHttpRequestمتصل شود. این برای جلوگیری از استخراج داده حیاتی است.frame-ancestors: این دستورالعمل مشخص می‌کند که کدام مبدأها می‌توانند صفحه شما را در یک<iframe>جاسازی کنند، و آن را به جایگزین مدرن و انعطاف‌پذیرتر هدرX-Frame-Optionsبرای جلوگیری از کلیک‌ربایی تبدیل می‌کند. تنظیم آن روی'none'یا'self'یک اقدام امنیتی قوی است.- گزارش‌دهی: از دستورالعمل
report-uriیاreport-toاستفاده کنید تا به مرورگر دستور دهید هر زمان که یک قانون CSP نقض شد، یک گزارش JSON به یک نقطه پایانی مشخص ارسال کند. این امر دید بی‌درنگ و ارزشمندی را در مورد حملات تلاش شده یا پیکربندی‌های نادرست فراهم می‌کند.
۲. یکپارچگی منابع فرعی (SRI): تأیید اسکریپت‌های شخص ثالث
هنگامی که شما یک اسکریپت را از یک شبکه تحویل محتوای (CDN) شخص ثالث بارگیری می‌کنید، به این اعتماد می‌کنید که آن CDN به خطر نیفتاده است. یکپارچگی منابع فرعی (SRI) این نیاز به اعتماد را با اجازه دادن به مرورگر برای تأیید اینکه فایلی که دریافت می‌کند دقیقاً همان فایلی است که شما قصد بارگیری آن را داشتید، از بین می‌برد.
چگونه کار می‌کند: شما یک هش رمزنگاری شده (مانند SHA-384) از اسکریپت مورد انتظار را در تگ <script> ارائه می‌دهید. مرورگر اسکریپت را دانلود می‌کند، هش خود را محاسبه می‌کند و آن را با هشی که شما ارائه داده‌اید مقایسه می‌کند. اگر مطابقت نداشته باشند، مرورگر از اجرای اسکریپت خودداری می‌کند.
مثال پیاده‌سازی:
<script src="https://code.jquery.com/jquery-3.6.0.min.js"
integrity="sha384-vtXRMe3mGCbOeY7l30aIg8H9p3GdeSe4IFlP6G8JMa7o7lXvnz3GFKzPxzJdPfGK"
crossorigin="anonymous"></script>
SRI یک کنترل ضروری برای هر منبعی است که از یک دامنه خارجی بارگیری می‌شود. این یک تضمین قوی در برابر به خطر افتادن CDN که منجر به اجرای کد مخرب در سایت شما می‌شود، فراهم می‌کند.
۳. پاک‌سازی ورودی و کُدگذاری خروجی: هسته پیشگیری از XSS
در حالی که CSP یک شبکه ایمنی قدرتمند است، دفاع اساسی در برابر XSS در مدیریت صحیح داده‌های ارائه‌شده توسط کاربر نهفته است. تمایز بین پاک‌سازی (sanitization) و کُدگذاری (encoding) بسیار مهم است.
- پاک‌سازی ورودی: این شامل تمیز کردن یا فیلتر کردن ورودی کاربر روی سرور قبل از ذخیره شدن آن است. هدف، حذف یا خنثی کردن کاراکترها یا کدهای بالقوه مخرب است. به عنوان مثال، حذف تگ‌های
<script>. با این حال، این روش شکننده است و می‌توان آن را دور زد. بهتر است از آن برای اعمال فرمت‌های داده (مثلاً اطمینان از اینکه شماره تلفن فقط شامل ارقام است) استفاده شود تا به عنوان یک کنترل امنیتی اصلی. - کُدگذاری خروجی: این مهم‌ترین و قابل اعتمادترین دفاع است. این شامل escape کردن داده‌ها بلافاصله قبل از اینکه در سند HTML نمایش داده شوند است، به طوری که مرورگر آن را به عنوان متن ساده تفسیر کند، نه کد قابل اجرا. زمینه کُدگذاری اهمیت دارد. به عنوان مثال:
- هنگام قرار دادن داده در داخل یک عنصر HTML (مانند
<div>)، باید آن را با HTML کُدگذاری کنید (مثلاً<به<تبدیل می‌شود). - هنگام قرار دادن داده در داخل یک ویژگی HTML (مانند
value="...")، باید آن را با کُدگذاری ویژگی (attribute-encode) انجام دهید. - هنگام قرار دادن داده در داخل یک رشته جاوا اسکریپت، باید آن را با کُدگذاری جاوا اسکریپت انجام دهید.
- هنگام قرار دادن داده در داخل یک عنصر HTML (مانند
بهترین شیوه: از کتابخانه‌های استاندارد و کاملاً بررسی‌شده برای کُدگذاری خروجی که توسط چارچوب وب شما ارائه می‌شود (مثلاً Jinja2 در پایتون، ERB در روبی، Blade در PHP) استفاده کنید. در سمت کلاینت، برای مدیریت ایمن HTML از منابع غیرقابل اعتماد، از کتابخانه‌ای مانند DOMPurify استفاده کنید. هرگز سعی نکنید روال‌های کُدگذاری یا پاک‌سازی خود را بسازید.
۴. هدرها و کوکی‌های امن: مستحکم‌سازی لایه HTTP
بسیاری از آسیب‌پذیری‌های سمت کلاینت را می‌توان با پیکربندی هدرهای HTTP امن و ویژگی‌های کوکی کاهش داد. اینها به مرورگر دستور می‌دهند تا خط‌مشی‌های امنیتی سخت‌گیرانه‌تری را اعمال کند.
هدرهای ضروری HTTP:
Strict-Transport-Security (HSTS): به مرورگر دستور می‌دهد که فقط از طریق HTTPS با سرور شما ارتباط برقرار کند، که از حملات کاهش سطح پروتکل (protocol downgrade) جلوگیری می‌کند.X-Content-Type-Options: nosniff: از تلاش مرورگر برای حدس زدن (MIME-sniffing) نوع محتوای یک منبع جلوگیری می‌کند، که می‌تواند برای اجرای اسکریپت‌هایی که به عنوان انواع فایل دیگر پنهان شده‌اند، مورد سوء استفاده قرار گیرد.Referrer-Policy: strict-origin-when-cross-origin: کنترل می‌کند که چه مقدار اطلاعات ارجاع‌دهنده (referrer) با درخواست‌ها ارسال شود، و از نشت داده‌های حساس URL به اشخاص ثالث جلوگیری می‌کند.
ویژگی‌های کوکی امن:
HttpOnly: این یک ویژگی حیاتی است. این ویژگی یک کوکی را از طریق APIdocument.cookieبرای جاوا اسکریپت سمت کلاینت غیرقابل دسترس می‌کند. این دفاع اصلی شما در برابر سرقت توکن جلسه از طریق XSS است.Secure: تضمین می‌کند که مرورگر کوکی را فقط از طریق یک اتصال HTTPS رمزگذاری شده ارسال کند.SameSite: مؤثرترین دفاع در برابر CSRF. این ویژگی کنترل می‌کند که آیا یک کوکی با درخواست‌های بین سایتی ارسال شود یا خیر.SameSite=Strict: کوکی فقط برای درخواست‌هایی که از همان سایت منشأ می‌گیرند ارسال می‌شود. قوی‌ترین محافظت را فراهم می‌کند.SameSite=Lax: یک تعادل خوب. کوکی در درخواست‌های فرعی بین سایتی (مانند تصاویر یا فریم‌ها) ارسال نمی‌شود اما زمانی که کاربر از یک سایت خارجی به URL می‌رود (مثلاً با کلیک روی یک لینک) ارسال می‌شود. این حالت پیش‌فرض در اکثر مرورگرهای مدرن است.
۵. مدیریت وابستگی‌های شخص ثالث و امنیت زنجیره تأمین
امنیت برنامه شما تنها به اندازه ضعیف‌ترین وابستگی آن قوی است. یک آسیب‌پذیری در یک بسته npm کوچک و فراموش‌شده می‌تواند منجر به یک خطر امنیتی تمام‌عیار شود.
اقدامات عملی برای امنیت زنجیره تأمین:
- اسکن خودکار آسیب‌پذیری: ابزارهایی مانند Dependabot گیت‌هاب، Snyk یا `npm audit` را در خط لوله CI/CD خود ادغام کنید. این ابزارها به طور خودکار وابستگی‌های شما را با پایگاه‌های داده آسیب‌پذیری‌های شناخته‌شده مقایسه کرده و شما را از خطرات آگاه می‌سازند.
- از یک فایل قفل (Lockfile) استفاده کنید: همیشه یک فایل قفل (
package-lock.json،yarn.lock) را به مخزن خود commit کنید. این کار تضمین می‌کند که هر توسعه‌دهنده و هر فرآیند ساخت از نسخه دقیقاً یکسان هر وابستگی استفاده می‌کند و از به‌روزرسانی‌های غیرمنتظره و بالقوه مخرب جلوگیری می‌کند. - وابستگی‌های خود را بررسی کنید: قبل از افزودن یک وابستگی جدید، بررسی‌های لازم را انجام دهید. محبوبیت، وضعیت نگهداری، تاریخچه مشکلات و سابقه امنیتی آن را بررسی کنید. یک کتابخانه کوچک و نگهداری‌نشده ریسک بیشتری نسبت به یک کتابخانه پرکاربرد و با پشتیبانی فعال دارد.
- وابستگی‌ها را به حداقل برسانید: هرچه وابستگی‌های کمتری داشته باشید، سطح حمله شما کوچکتر خواهد بود. به طور دوره‌ای پروژه خود را بازبینی کرده و بسته‌های استفاده‌نشده را حذف کنید.
۶. حفاظت و نظارت در زمان اجرا (Runtime)
دفاع‌های ایستا ضروری هستند، اما یک استراتژی جامع همچنین شامل نظارت بر عملکرد کد شما در زمان واقعی در مرورگر کاربر است.
اقدامات امنیتی در زمان اجرا:
- سندباکس کردن جاوا اسکریپت: برای اجرای کدهای شخص ثالث با ریسک بالا (مثلاً در یک ویرایشگر کد آنلاین یا یک سیستم افزونه)، از تکنیک‌هایی مانند iframeهای سندباکس شده با CSPهای سخت‌گیرانه برای محدود کردن شدید قابلیت‌های آنها استفاده کنید.
- نظارت رفتاری: راه‌حل‌های امنیتی سمت کلاینت می‌توانند رفتار زمان اجرای همه اسکریپت‌ها را در صفحه شما نظارت کنند. آنها می‌توانند فعالیت‌های مشکوک را در زمان واقعی شناسایی و مسدود کنند، مانند تلاش اسکریپت‌ها برای دسترسی به فیلدهای حساس فرم، درخواست‌های شبکه غیرمنتظره که نشان‌دهنده استخراج داده است، یا تغییرات غیرمجاز در DOM.
- ثبت لاگ متمرکز: همانطور که در مورد CSP ذکر شد، رویدادهای مرتبط با امنیت را از سمت کلاینت جمع‌آوری کنید. ثبت نقض‌های CSP، بررسی‌های ناموفق یکپارچگی و سایر ناهنجاری‌ها در یک سیستم متمرکز مدیریت اطلاعات و رویدادهای امنیتی (SIEM)، به تیم امنیتی شما اجازه می‌دهد تا روندها را شناسایی کرده و حملات در مقیاس بزرگ را کشف کنند.
جمع‌بندی همه چیز: یک مدل دفاعی لایه‌ای
هیچ کنترل واحدی راه‌حل جادویی نیست. قدرت این چارچوب در لایه‌بندی این دفاع‌ها نهفته است به طوری که یکدیگر را تقویت کنند.
- تهدید: XSS از محتوای تولید شده توسط کاربر.
- لایه ۱ (اصلی): کُدگذاری خروجی آگاه از زمینه (Context-aware) از تفسیر داده‌های کاربر به عنوان کد توسط مرورگر جلوگیری می‌کند.
- لایه ۲ (ثانویه): یک خط مشی امنیت محتوای (CSP) سخت‌گیرانه از اجرای اسکریپت‌های غیرمجاز جلوگیری می‌کند، حتی اگر یک باگ در کُدگذاری وجود داشته باشد.
- لایه ۳ (ثالثیه): استفاده از کوکی‌های
HttpOnlyاز مفید بودن توکن جلسه سرقت‌شده برای مهاجم جلوگیری می‌کند.
- تهدید: یک اسکریپت تحلیل شخص ثالث به خطر افتاده.
- لایه ۱ (اصلی): یکپارچگی منابع فرعی (SRI) باعث می‌شود مرورگر از بارگیری اسکریپت تغییر یافته جلوگیری کند.
- لایه ۲ (ثانویه): یک CSP سخت‌گیرانه با
script-srcوconnect-srcمشخص، محدود می‌کند که اسکریپت به خطر افتاده چه کاری می‌تواند انجام دهد و داده‌ها را به کجا می‌تواند ارسال کند. - لایه ۳ (ثالثیه): نظارت در زمان اجرا می‌تواند رفتار ناهنجار اسکریپت (مثلاً تلاش برای خواندن فیلدهای رمز عبور) را شناسایی و آن را مسدود کند.
نتیجه‌گیری: تعهد به امنیت مستمر
ایمن‌سازی جاوا اسکریپت سمت کلاینت یک پروژه یک‌باره نیست؛ بلکه یک فرآیند مستمر از هوشیاری، انطباق و بهبود است. چشم‌انداز تهدیدات به طور مداوم در حال تحول است و مهاجمان تکنیک‌های جدیدی برای دور زدن دفاع‌ها توسعه می‌دهند. با اتخاذ یک چارچوب ساختاریافته و چند لایه که بر پایه اصول مستحکم بنا شده، شما از یک وضعیت واکنشی به یک وضعیت پیشگیرانه حرکت می‌کنید.
این چارچوب—که ترکیبی از خط‌مشی‌های قوی مانند CSP، تأیید با SRI، بهداشت اساسی مانند کُدگذاری، مستحکم‌سازی از طریق هدرهای امن، و هوشیاری از طریق اسکن وابستگی‌ها و نظارت در زمان اجرا است—یک طرح قدرتمند برای سازمان‌ها در سراسر جهان فراهم می‌کند. همین امروز با ممیزی برنامه‌های خود در برابر این کنترل‌ها شروع کنید. پیاده‌سازی این دفاع‌های لایه‌ای را برای محافظت از داده‌های خود، کاربران خود و اعتبار خود در دنیایی که به طور فزاینده‌ای به هم متصل است، در اولویت قرار دهید.