diff --git a/.gitignore b/.gitignore
index 6be2e5ba..ba7745cc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,6 +41,10 @@
 !docs/pt-br/index.md
 !docs/pt-br/**/
 !docs/pt-br/**/*.md
+!docs/fa/
+!docs/fa/index.md
+!docs/fa/**/
+!docs/fa/**/*.md
 !docs/CNAME
 
 # ignore symbolic links
diff --git a/docs/fa/02-foundations/01-security-fundamentals.md b/docs/fa/02-foundations/01-security-fundamentals.md
new file mode 100644
index 00000000..6f207ef2
--- /dev/null
+++ b/docs/fa/02-foundations/01-security-fundamentals.md
@@ -0,0 +1,164 @@
+اصول پایه‌ای امنیت اپلیکیشن بر مفاهیم امنیتی بیان شده در این راهنما استوار است و این در اصل یک راهنما برای
+توسعه‌دهندگان است.
+
+هدف این بخش، ارائه مقدمه‌ای بر اصول پایه و اولیه است که هر تیم توسعه‌ای باید با آن‌ها آشنا باشد.
+
+#### مدل تضمین تکامل نرم‌افزار (Software Assurance Maturity Model)
+
+مدل بلوغ تضمین نرم‌افزار ([SAMM][samm]) زمینه‌ای برای دامنه امنیت نرم‌افزار و بنیان‌های یک رویه امنیتی خوب
+فراهم می‌کند:
+
+- [حاکمیت (Governance)][sammg]
+- [طراحی (Design)][sammd]
+- [پیاده‌سازی (Implementation)][sammi]
+- [راستی‌آزمایی (Verification)][sammv]
+- [عملیات (Operations)][sammo]
+
+مدل SAMM این بنیان‌های امنیت نرم‌افزار را به عنوان عملکردهای تجاری (Business Functions) توصیف می‌کند که
+خود به رویه‌های تجاری (Business Practices) تقسیم می‌شوند.
+
+مدل تضمین تکامل نرم‌افزار ([SAMM][samm]) در سرتاسر این راهنمای توسعه استفاده شده است؛ اکثر بخش‌های این
+راهنما حداقل به یکی از کارکردهای تجاری یا رویه‌های SAMM اشاره می‌کند.
+
+#### سه‌گانه CIA
+
+امنیت به زبان ساده، کنترل این است که چه کسی می‌تواند با اطلاعات شما تعامل داشته باشد، چه کاری می‌تواند
+با آن انجام دهد و چه زمانی می‌تواند با آن تعامل داشته باشد. این ویژگی‌های امنیت را می‌توان با استفاده از
+سه‌گانه CIA تعریف کرد.
+
+CIA مخفف محرمانگی (Confidentiality)، یکپارچگی (Integrity) و دسترس‌پذیری (Availability) است و معمولاً
+به صورت یک مثلث که نمایانگر ارتباط قوی بین سه اصل آن است، به تصویر کشیده می‌شود. این سه‌گانه به عنوان
+پایه‌های امنیت اپلیکیشن در نظر گرفته می‌شود و اغلب محرمانگی، یکپارچگی یا دسترس‌پذیری به عنوان ویژگی‌های
+اطلاعات یا فرآیندها در یک سیستم معین استفاده می‌شوند. سه‌گانه CIA را می‌توان با سه‌گانه AAA بسط داد:
+مجوزدهی (Authorization)، احراز هویت (Authentication) و حسابرسی (Auditing).
+
+#### محرمانگی (Confidentiality)
+
+محرمانگی، حفاظت از داده‌ها در برابر افشای غیرمجاز است؛ این مفهوم به معنای تضمین این است که فقط افرادی
+با مجوز صحیح می‌توانند به داده‌ها دسترسی داشته باشند و هم برای داده‌های ثابت (data at rest) و هم برای
+داده‌های در حال انتقال (data in transit) اعمال می‌شود.
+
+محرمانگی همچنین با مفهوم گسترده‌تر حریم خصوصی داده‌ها مرتبط است.
+
+#### یکپارچگی (Integrity)
+
+یکپارچگی به معنای محافظت از داده‌ها در برابر تغییرات غیرمجاز یا تضمین قابل اعتماد بودن داده‌ها است.
+این مفهوم شامل ایده پایداری داده‌ها (داده‌ها به صورت تصادفی یا عمدی تغییر نکرده‌اند) و ایده یکپارچگی
+منبع (داده‌ها از یک منبع قانونی آمده یا توسط آن تغییر کرده‌اند) می‌باشد.
+
+#### دسترس‌پذیری (Availability)
+
+دسترس‌پذیری به معنای تضمین حضور اطلاعات یا منابع است. این مفهوم نه تنها به در دسترس بودن خود داده‌ها
+(مثلاً با استفاده از تکثیر داده‌ها) بلکه به محافظت از سرویس‌هایی که دسترسی به داده‌ها را فراهم می‌کنند
+(مثلاً با استفاده از توزیع بار یا load balancing) نیز متکی است.
+
+#### سه‌گانه AAA
+
+سه‌گانه CIA اغلب با احراز هویت (Authentication)، مجوزدهی (Authorization) و حسابرسی (Auditing) گسترش
+می‌یابد، زیرا این موارد ارتباط نزدیکی با مفاهیم CIA دارند. CIA وابستگی شدیدی به احراز هویت و مجوزدهی
+دارد؛ محرمانگی و یکپارچگی داده‌های حساس بدون آن‌ها قابل تضمین نیست. حسابرسی به این دلیل اضافه می‌شود که
+می‌تواند مکانیزمی برای اطمینان از اثبات هرگونه تعامل با سیستم فراهم کند.
+
+#### احراز هویت (Authentication)
+
+[احراز هویت](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) به معنای
+صحت‌سنجی موجودیتی است که می‌خواهد با یک سیستم امن تعامل داشته باشد.
+
+به عنوان مثال، این موجودیت می‌تواند یک مکانیسم خودکار یا یک عامل انسانی باشد؛ در هر دو حالت، احراز هویت
+برای یک اپلیکیشن امن الزامی است.
+
+#### مجوزدهی (Authorization)
+
+[مجوزدهی](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) به معنای مشخص
+کردن حقوق دسترسی به منابع امن (داده‌ها، سرویس‌ها، فایل‌ها، اپلیکیشن‌ها و غیره) است.
+
+این حقوق، سطوح دسترسی مربوط به منابعی که در حال ایمن‌سازی هستند، توصیف می‌کنند.
+
+مجوزدهی معمولاً پس از احراز هویت موفق انجام می‌شود.
+
+#### تعقیب و مراقبت (Auditing)
+
+حسابرسی به معنای پیگیری رویدادهای سطح پیاده‌سازی و همچنین رویدادهای سطح دامنه (domain-level) است که
+در یک سیستم رخ می‌دهند.
+
+این امر به فراهم کردن مفهوم عدم انکار (non-repudiation) کمک می‌کند، به این معنی که تغییرات یا اقدامات
+انجام شده بر روی سیستم محافظت‌شده غیرقابل انکار هستند.
+
+سامانه‌های تعقیب و مراقبت نه تنها می‌تواند اطلاعات فنی در مورد سیستم در حال اجرا را فراهم کند، بلکه
+اثباتی برای انجام اقدامات خاصی نیز ارائه می‌دهد. سوالات متداولی که تعقیب و مراقبت به آن‌ها پاسخ می‌دهد
+عبارتند از: «چه کسی، چه کاری را، چه زمانی و احتمالاً چگونه انجام داده است؟»
+
+#### آسیب‌پذیری‌ها (Vulnerabilities)
+
+NIST یک [آسیب‌پذیری][nistvuln] را اینگونه تعریف می‌کند: «ضعف در یک سیستم اطلاعاتی، رویه‌های امنیتی سیستم،
+کنترل‌های داخلی یا پیاده‌سازی که می‌تواند توسط یک منبع تهدید مورد بهره‌برداری یا فعال‌سازی قرار گیرد.»
+
+در هر اپلیکیشن بزرگی ضعف‌ها یا باگ‌های زیادی وجود دارد، اما اصطلاح آسیب‌پذیری عموماً برای آن دسته از
+ضعف‌ها یا باگ‌هایی به کار می‌رود که این خطر وجود دارد که یک مهاجم بتواند با سواستفاده از آن‌ها یک تهدید
+برای سیستم به وجود بیاورد.
+
+آسیب‌پذیری‌های امنیتی شناخته‌شده عبارتند از:
+
+- [دزدیدن کلیک (Clickjacking)](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html)
+- [حمله با اعتبارنامه‌های سرقت‌شده (Credential Stuffing)](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html)
+- [نشت اطلاعات بین سایتی (Cross-site leaks)][csxsleaks]
+- [حملات نفی سرویس (Denial of Service)](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) (DoS)
+- حملات [XSS مبتنی بر DOM](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html) شامل [DOM Clobbering](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html)
+- [IDOR](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html)
+- [تزریق (Injection)](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) شامل [تزریق دستور سیستم‌عامل](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html) و [XXE][csxxe]
+- [حملات تزریق مخصوص LDAP](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html)
+- [آلودگی پروتوتایپ در جاوا اسکریپت (Prototype pollution)](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html)
+- حملات [SSRF][csssrf]
+- [تزریق SQL](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) و استفاده از [کوئری](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) های پارامتری
+- [تغییر ریدایرکت و فورواردهای اعتبارسنجی‌نشده](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html)
+- حملات [XSS][csxss] و [دور زدن فیلتر XSS][csxssevade]
+
+#### HTTP و HTML
+
+اگرچه HTTP و HTML به خودی خود از اصول بنیادین امنیت نیستند، اما اپلیکیشن‌های وب به ارتباطات HTTP و HTML
+متکی هستند. هم توسعه‌دهندگان اپلیکیشن و هم مهندسان امنیت باید درک خوبی از HTTP و زبان HTML به همراه
+کنترل‌های امنیتی مختلف آن‌ها داشته باشند.
+
+اکثر تیم‌های توسعه اپلیکیشن با ارتباطات HTTP و استاندارد HTML آشنا هستند، اما در صورت لزوم به
+آموزش‌های [w3consortium] یا [W3 Schools][w3schools] مراجعه کنید. [مجموعه برگه‌های تقلب OWASP](https://cheatsheetseries.owasp.org/)
+اطلاعات مورد نیاز برای تولید نرم‌افزار امن را در اختیار توسعه‌دهندگان اپلیکیشن‌های وب قرار می‌دهد:
+
+- برگه تقلب [امنیت HTML5](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html) طیف گسترده‌ای از کنترل‌ها را، مطابق با [استاندارد زنده HTML][htmlliving] فعلی، توصیف می‌کند.
+- برای CSS به برگه تقلب [CSS](https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.html) مراجعه کنید.
+- هدرهای HTTP باید امن باشند، برگه تقلب [هدرهای پاسخ امنیتی HTTP](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) را ببینید.
+- [امنیت انتقال اکید HTTP][csstrict] را قویاً مد نظر قرار دهید.
+- اگر اپلیکیشن قابلیت آپلود فایل دارد، از برگه تقلب [آپلود فایل](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) پیروی کنید.
+- با استفاده از برگه تقلب [سیاست امنیت محتوا](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)، از وجود سیاست امنیت محتوا اطمینان حاصل کنید.
+- از JWT برای یک اپلیکیشن جاوا استفاده می‌کنید؟ به برگه تقلب [توکن وب JSON](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) مراجعه کنید.
+- اشیاء را ذخیره یا ارسال می‌کنید؟ برگه تقلب [Deserialization (وارسیال‌سازی)](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) را بررسی کنید.
+
+#### منابع
+
+- [استاندارد زنده HTML][htmlliving] [WHATWG]
+- OWASP [مجموعه برگه‌های تقلب](https://cheatsheetseries.owasp.org/)
+- OWASP [مدل بلوغ تضمین نرم‌افزار][samm] (SAMM)
+
+---
+
+راهنمای توسعه‌دهنده OWASP یک تلاش اجتماعی است؛ اگر چیزی نیاز به تغییر دارد، لطفاً
+[یک ایشو ثبت کنید][issue0401] یا [در گیت‌هاب ویرایش کنید][edit0401].
+
+[csssrf]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
+[csstrict]: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html
+[csxss]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
+[csxsleaks]: https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html
+[csxssevade]: https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html
+[csxxe]: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html
+[edit0401]: https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/01-security-fundamentals.md
+[htmlliving]: https://html.spec.whatwg.org/multipage/
+[issue0401]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/01-security-fundamentals
+[nistvuln]: https://csrc.nist.gov/glossary/term/vulnerability
+[samm]: https://owaspsamm.org/about/
+[sammd]: https://owaspsamm.org/model/design/
+[sammg]: https://owaspsamm.org/model/governance/
+[sammi]: https://owaspsamm.org/model/implementation/
+[sammo]: https://owaspsamm.org/model/operations/
+[sammv]: https://owaspsamm.org/model/verification/
+[w3consortium]: https://www.w3.org/
+[w3schools]: https://www.w3schools.com/html/
+[whatwg]: <https://whatwg.org/>
\ No newline at end of file
diff --git a/docs/fa/02-foundations/02-secure-development.md b/docs/fa/02-foundations/02-secure-development.md
new file mode 100644
index 00000000..25b90733
--- /dev/null
+++ b/docs/fa/02-foundations/02-secure-development.md
@@ -0,0 +1,212 @@
+توسعه امن در استفاده‌های تجاری [طراحی][sammd]، [پیاده‌سازی][sammi] و [اعتبارسنجی][sammv] از مدل تضمین
+تکامل نرم‌افزار OWASP یا ([SAMM][samm]) توصیف شده است.
+
+همچنین برای توضیحی مناسب در مورد اینکه چرا افزودن امنیت به چرخه حیات توسعه نرم‌افزار مهم است،
+به [فرهنگ امنیت][culturewhy] مراجعه کنید.
+
+#### پیش‌درآمد
+
+بهترین مقدمه برای توسعه نرم‌افزار امن کاربردی، مقاله [تجزیه امنیت اپلیکیشن][sdlc] از OWASP است:
+
+_یا چگونه کمتر نگران شدم و بر شانه‌های غول‌ها ایستادم._ - اسپایروس گاستراتوس، الی سعد
+
+بخش بزرگی از مطالب این بخش از پروژه [استانداردهای یکپارچه‌سازی][intstand] OWASP گرفته شده است.
+
+#### مرور کلی
+
+تقریباً تمام نرم‌افزارهای مدرن به شیوه‌ای تکرارشونده توسعه می‌یابند و از مرحله‌ای به مرحله دیگر عبور
+می‌کنند، مانند شناسایی نیازمندی‌های مشتری، پیاده‌سازی و تست. این مراحل به صورت چرخه‌ای در طول عمر
+اپلیکیشن تکرار می‌شوند. یک چرخه حیات توسعه نرم‌افزار (SDLC) مفهومی در زیر نشان داده شده است، در عمل ممکن
+است مراحل کمتر یا بیشتری بسته به فرآیندهای اتخاذ شده توسط سازمان وجود داشته باشد.
+
+![چرخه حیات SDLC](../../assets/images/sdlc_diag.png){ align=right width=180 }
+
+با افزایش تعداد و پیچیدگی اکسپلویت‌ها علیه تقریباً هر اپلیکیشن یا سیستم تجاری، اکثر شرکت‌ها یک چرخه
+حیات توسعه نرم‌افزار امن (Secure SDLC) را اتخاذ کرده‌اند. SDLC امن هرگز نباید یک چرخه حیات جدا از
+چرخه حیات توسعه نرم‌افزار موجود باشد؛ بلکه باید همیشه همان چرخه حیات توسعه قبلی باشد اما با اقدامات
+امنیتی که در هر مرحله تعبیه شده است.
+
+در غیر این صورت، ممکن است اقدامات امنیتی توسط تیم‌های توسعه پرمشغله کنار گذاشته شوند.
+توجه داشته باشید که اگرچه Secure SDLC می‌تواند به صورت 'SSDLC' نوشته شود، اما تقریباً همیشه به صورت
+'SDLC' نوشته می‌شود.
+
+DevOps بسیاری از مراحل SDLC را یکپارچه و خودکار کرده و پایپ‌لاین‌های یکپارچه‌سازی مداوم (CI) و
+تحویل/استقرار مداوم (CD) را برای فراهم کردن بخش بزرگی از اتوماسیون SDLC پیاده‌سازی می‌کند.
+
+DevOps و پایپ‌لاین‌ها با عواقب جدی در مقیاس بزرگ با موفقیت مورد اکسپلویت قرار گرفته‌اند و بنابراین،
+به روشی مشابه SDLC، بسیاری از اقدامات DevOps نیز امنیت را در خود جای داده‌اند. DevOps امن، یا DevSecOps،
+رویه‌های امنیتی را در فعالیت‌های DevOps تعبیه می‌کند تا در برابر حملات محافظت کرده و تست امنیت خودکار
+را برای SDLC فراهم کند.
+
+نمونه‌هایی از چگونگی «پیاده‌سازی امنیت» در DevSecOps، فراهم کردن تست امنیت اپلیکیشن تعاملی، ایستا و
+پویا (IAST, SAST & DAST) و پیاده‌سازی امنیت زنجیره تأمین است، و فعالیت‌های امنیتی بسیار دیگری نیز
+وجود دارد که می‌توانند اعمال شوند. برای اطلاع از آخرین کنترل‌های امنیتی DevSecOps به
+[برگه تقلب امنیت CI/CD][cscicd] مراجعه کنید.
+
+#### چرخه حیات توسعه امن
+
+با مراجعه به چرخه توسعه [راهنمای امنیت اپلیکیشن][intstand] OWASP، چهار مرحله تکرارشونده در طول توسعه
+اپلیکیشن وجود دارد: نیازمندی‌ها، طراحی، پیاده‌سازی و راستی‌آزمایی. مراحل دیگر کمتر به صورت تکراری در
+چرخه توسعه انجام می‌شوند اما بخش به همان اندازه مهمی از SDLC را تشکیل می‌دهند: تحلیل شکاف (Gap Analysis)،
+معیارها (Metrics)، عملیات (Operation) و آموزش و فرهنگ‌سازی (Training & Culture Building).
+
+تمام این مراحل SDLC باید فعالیت‌های امنیتی را در خود داشته باشند، به جای اینکه به عنوان فعالیت‌های
+جداگانه انجام شوند. اگر امنیت در این مراحل تعبیه شود، سربار آن بسیار کمتر شده و مقاومت تیم‌های توسعه
+در این مورد کاهش می‌یابد. هدف این است که SDLC امن به یک فرآیند آشنا مانند قبل تبدیل شود و تیم‌های توسعه
+مالکیت فعالیت‌های امنیتی در هر مرحله را بر عهده بگیرند.
+
+ابزارها و منابع بسیاری از OWASP برای کمک به اعمال امنیت در SDLC وجود دارد.
+
+* **نیازمندی‌ها (Requirements)**: این مرحله نیازمندی‌های عملکردی، غیرعملکردی و امنیتی اپلیکیشن را
+  تعیین می‌کند. نیازمندی‌ها باید به صورت دوره‌ای بازبینی شده و از نظر کامل بودن و اعتبار بررسی شوند،
+  و ارزش دارد که ابزارهای مختلف OWASP برای کمک به این امر در نظر گرفته شوند؛
+  * [استاندارد راستی‌آزمایی امنیت اپلیکیشن (ASVS)][asvs] لیستی از نیازمندی‌ها برای توسعه امن را در
+    اختیار توسعه‌دهندگان قرار می‌دهد،
+  * پروژه [امنیت اپلیکیشن موبایل][masproject] یک استاندارد امنیتی برای اپلیکیشن‌های موبایل فراهم می‌کند
+  * و [SecurityRAT][srat] به شناسایی مجموعه اولیه و پایه نیازمندی‌های امنیتی کمک می‌کند.
+
+* **طراحی (Design)**: طراحی امنیت در اپلیکیشن مهم است - هیچ وقت برای این کار دیر نیست اما هرچه زودتر
+  انجام شود بهتر و آسان‌تر است. OWASP دو ابزار، [مدل‌سازی تهدید پایتونیک][pytm] و [اژدهای تهدید][tdtm]،
+  برای مدل‌سازی تهدید به همراه بازی کردن امنیت با استفاده از [Cornucopia][cornucopia] فراهم می‌کند.
+
+* **پیاده‌سازی (Implementation)**: پروژه [۱۰ کنترل پیشگیرانه برتر][proactive10] OWASP بیان می‌کند که آنها
+  «مهم‌ترین کنترل‌ها و دسته‌های کنترلی هستند که هر توسعه‌دهنده‌ای باید مطلقاً، ۱۰۰٪ در هر پروژه‌ای
+  بگنجاند» و این قطعاً توصیه خوبی است. پیاده‌سازی این کنترل‌ها می‌تواند درجه بالایی از اطمینان را فراهم
+  کند که اپلیکیشن یا سیستم به طور منطقی امن خواهد بود. OWASP دو کتابخانه را فراهم می‌کند که می‌توانند
+  در اپلیکیشن‌های وب گنجانده شوند، کتابخانه کنترل امنیتی [API امنیت سازمانی (ESAPI)][esapi-project] و
+  [CSRFGuard][csrfguard] برای کاهش خطر حملات [جعل درخواست بین سایتی][cscsrf] (CSRF)، که به پیاده‌سازی
+  این کنترل‌های پیشگیرانه کمک می‌کنند. علاوه بر این، [مجموعه برگه‌های تقلب][csproject] OWASP منبع
+  ارزشمندی از اطلاعات و توصیه‌ها در مورد تمام جنبه‌های امنیت اپلیکیشن‌ها است.
+
+* **راستی‌آزمایی (Verification)**: OWASP تعداد نسبتاً زیادی پروژه را فراهم می‌کند که به تست و راستی‌آزمایی
+  کمک می‌کنند. این موضوع یک بخش در این راهنمای توسعه‌دهنده است و پروژه‌ها در انتهای این بخش لیست شده‌اند.
+
+* **آموزش (Training)**: تیم‌های توسعه به طور مداوم به آموزش امنیت نیاز دارند. اگرچه آموزش بخشی از حلقه
+  تکراری داخلی SDLC نیست، اما همچنان باید در چرخه حیات پروژه لحاظ شود. OWASP بسیاری از محیط‌ها و
+  مواد آموزشی را فراهم می‌کند - لیست را در انتهای این بخش ببینید.
+
+* **فرهنگ‌سازی (Culture Building)**: یک فرهنگ امنیتی خوب در یک سازمان تجاری به میزان زیادی به امن نگه
+  داشتن اپلیکیشن‌ها و سیستم‌ها کمک خواهد کرد. فعالیت‌های زیادی وجود دارند که همگی با هم فرهنگ امنیت
+  را ایجاد می‌کنند، پروژه [فرهنگ امنیت][culture] OWASP به جزئیات بیشتری در مورد این فعالیت‌ها می‌پردازد،
+  و یک برنامه قهرمانان امنیت (Security Champion) خوب در کسب‌وکار، بنیادی برای یک وضعیت امنیتی خوب است.
+  این راهنمای OWASP راهنمایی و مواد لازم را برای ایجاد قهرمانان امنیت در تیم‌های توسعه فراهم می‌کند.
+  در حالت ایده‌آل، هر تیم باید یک قهرمان امنیت داشته باشد که علاقه خاصی به امنیت دارد و آموزش بیشتری
+  دیده است، که این امر تیم را قادر می‌سازد تا امنیت را در کار خود تعبیه کند.
+
+* **عملیات (Operations)**: [راهنمای DevSecOps][devsecops] OWASP توضیح می‌دهد که چگونه می‌توان یک پایپ‌لاین
+  امن را به بهترین شکل پیاده‌سازی کرد، با استفاده از بهترین رویه‌ها و ابزارهای اتوماسیون برای کمک به
+  «انتقال به چپ» (shift-left) مسائل امنیتی. برای اطلاعات بیشتر در مورد هر یک از موضوعات درون DevSecOps
+  و به ویژه بخش‌های مربوط به عملیات، به راهنمای DevSecOps مراجعه کنید.
+
+* **زنجیره تأمین (Supply chain)**: حملاتی که از زنجیره تأمین بهره‌برداری می‌کنند می‌توانند ویرانگر باشند
+  و چندین مورد برجسته از محصولات که با موفقیت مورد اکسپلویت قرار گرفته‌اند، وجود داشته است. یک فهرست
+  مواد نرم‌افزار (SBOM) اولین قدم برای جلوگیری از این حملات است و ارزش دارد که از استاندارد فهرست
+  مواد (BOM) تمام پشته [CycloneDX][cyclone] OWASP برای [کاهش ریسک در زنجیره تأمین][cschain] استفاده شود.
+  علاوه بر این، پروژه [Dependency-Track][deptrack] OWASP یک پلتفرم تحلیل مداوم SBOM است که می‌تواند با
+  فراهم کردن کنترل بر SBOM، به جلوگیری از این اکسپلویت‌های زنجیره تأمین کمک کند.
+
+* **وابستگی‌های شخص ثالث (Third party dependencies)**: پیگیری اینکه چه کتابخانه‌های شخص ثالثی در اپلیکیشن
+  گنجانده شده‌اند، و چه آسیب‌پذیری‌هایی دارند، به راحتی قابل خودکارسازی است. بسیاری از مخازن عمومی مانند
+  [github] و [gitlab] این سرویس را به همراه برخی از طراحان تجاری ارائه می‌دهند. OWASP ابزار تحلیل
+  ترکیب نرم‌افزار (SCA) [Dependency-Check][depcheck] را برای پیگیری کتابخانه‌های خارجی فراهم می‌کند.
+
+* **تست امنیت اپلیکیشن (Application security testing)**: انواع مختلفی از تست‌های امنیتی وجود دارد که
+  می‌توانند به صورت خودکار در زمان pull-request، merge یا به صورت شبانه اجرا شوند - یا در واقع به صورت
+  دستی، اما وقتی خودکار باشند قدرتمندتر هستند. معمولاً تست امنیت ایستا اپلیکیشن (SAST) وجود دارد که
+  کد را بدون اجرای آن تحلیل می‌کند، و تست امنیت پویای اپلیکیشن (DAST)، که ورودی را به اپلیکیشن در حال
+  اجرا در یک sandbox یا محیط‌های ایزوله دیگر اعمال می‌کند. تست امنیت تعاملی اپلیکیشن (IAST) برای اجرای
+  دستی و همچنین خودکار طراحی شده است، و بازخورد فوری در مورد تست‌ها هنگام اجرای آنها ارائه می‌دهد.
+
+#### مطالعه بیشتر از OWASP
+
+* [مجموعه برگه‌های تقلب][csproject]
+* [برگه تقلب امنیت CI/CD][cscicd]
+* [Cornucopia][cornucopia]
+* استاندارد فهرست مواد (BOM) [CycloneDX][cyclone]
+* [راهنمای DevSecOps][devsecops]
+* [راهنمای قهرمانان امنیت][champions]
+* [پروژه فرهنگ امنیت][culture]
+* [۱۰ کنترل پیشگیرانه برتر][proactive10]
+
+#### پروژه‌های راستی‌آزمایی OWASP
+
+* [استاندارد راستی‌آزمایی امنیت اپلیکیشن (ASVS)][asvs]
+* [پروژه Amass][amass]
+* [Code Pulse][pulse]
+* [Defect Dojo][defectdojo]
+* [امنیت اپلیکیشن موبایل (MAS)][masproject]
+* [Nettacker][net]
+* [چارچوب تست تهاجمی وب (OWTF)][owtf]
+* [راهنمای تست امنیت وب (WSTG)][wstg]
+
+#### پروژه‌های آموزشی OWASP
+
+* [پروژه امنیت API][apisec] (API Top 10)
+* [Juice Shop][juice]
+* [۱۰ مورد برتر موبایل][mobile10]
+* [Security Shepherd][sec-shep]
+* [Snakes And Ladders][snakes]
+* [ده ریسک امنیتی برتر اپلیکیشن وب][top10]
+* [WebGoat][webgoat]
+
+#### منابع OWASP
+
+* [کتابخانه CSRFGuard][csrfguard]
+* [تحلیل ترکیب نرم‌افزار (SCA) Dependency-Check][depcheck]
+* [پلتفرم تحلیل مداوم SBOM Dependency-Track][deptrack]
+* [API امنیت سازمانی (ESAPI)][esapi-project]
+* [راهنمای امنیت اپلیکیشن پروژه استانداردهای یکپارچه‌سازی][intstand]
+* [امنیت اپلیکیشن موبایل (MAS)][mas]
+* [مدل‌سازی تهدید پایتونیک][pytm]
+* [اژدهای تهدید][tdtm]
+* [SecurityRAT][srat] (ابزار خودکارسازی برای نیازمندی‌ها)
+
+---
+
+راهنمای توسعه‌دهنده OWASP یک تلاش اجتماعی است؛ اگر چیزی نیاز به تغییر دارد، لطفاً
+[یک ایشو (مسئله) ثبت کنید][issue0402] یا [در گیت‌هاب ویرایش کنید][edit0402].
+
+[amass]: https://owasp.org/www-project-amass/
+[apisec]: https://owasp.org/API-Security
+[asvs]: https://owasp.org/www-project-application-security-verification-standard/
+[champions]: https://owasp.org/www-project-security-champions-guidebook/
+[cscicd]: https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html
+[cornucopia]: https://owasp.org/www-project-cornucopia/
+[cschain]: https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html
+[cscsrf]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
+[csproject]: https://owasp.org/www-project-cheat-sheets/
+[csrfguard]: https://owasp.org/www-project-csrfguard/
+[culture]: https://owasp.org/www-project-security-culture/
+[culturewhy]: https://owasp.org/www-project-security-culture/stable/2-Why_Add_Security_In_Development_Teams/
+[cyclone]: https://owasp.org/www-project-cyclonedx/
+[depcheck]: https://owasp.org/www-project-dependency-check/
+[deptrack]: https://dependencytrack.org/
+[devsecops]: https://owasp.org/www-project-devsecops-guideline/
+[defectdojo]: https://www.defectdojo.org/
+[edit0402]: https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/02-secure-development.md
+[esapi-project]: https://owasp.org/www-project-enterprise-security-api/
+[github]: https://github.com/
+[gitlab]: https://about.gitlab.com/
+[issue0402]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/02-secure-development
+[juice]: https://owasp.org/www-project-juice-shop/
+[mas]: https://mas.owasp.org/
+[masproject]: https://owasp.org/www-project-mobile-app-security/
+[mobile10]: https://owasp.org/www-project-mobile-top-10/
+[net]: https://owasp.org/www-project-nettacker/
+[owtf]: https://owasp.org/www-project-owtf/
+[proactive10]: https://owasp.org/www-project-proactive-controls/
+[pulse]: https://owasp.org/www-project-code-pulse/
+[pytm]: https://owasp.org/www-project-pytm/
+[samm]: https://owaspsamm.org/about/
+[sammd]: https://owaspsamm.org/model/design/
+[sammi]: https://owaspsamm.org/model/implementation/
+[sammv]: https://owaspsamm.org/model/verification/
+[sdlc]: https://owasp.org/www-project-integration-standards/writeups/owasp_in_sdlc/
+[sec-shep]: https://owasp.org/www-project-security-shepherd/
+[snakes]: https://owasp.org/www-project-snakes-and-ladders/
+[srat]: https://owasp.org/www-project-securityrat/
+[tdtm]: https://owasp.org/www-project-threat-dragon/
+[top10]: https://owasp.org/Top10/
+[intstand]: https://owasp.org/www-project-integration-standards/
+[webgoat]: https://owasp.org/www-project-webgoat/
+[wstg]: https://owasp.org/www-project-web-security-testing-guide/
\ No newline at end of file
diff --git a/docs/fa/02-foundations/03-security-principles.md b/docs/fa/02-foundations/03-security-principles.md
new file mode 100644
index 00000000..ed58d0b5
--- /dev/null
+++ b/docs/fa/02-foundations/03-security-principles.md
@@ -0,0 +1,183 @@
+این بخش مقدمه‌ای بسیار کوتاه بر برخی مفاهیم مورد استفاده در حوزه امنیت نرم‌افزار است، چرا که این مفاهیم
+ممکن است برای بسیاری از توسعه‌دهندگان اپلیکیشن ناآشنا باشند. [مجموعه برگه‌های تقلب OWASP](https://cheatsheetseries.owasp.org/)
+توضیحات عمیق‌تری برای این اصول امنیتی ارائه می‌دهد؛ برای مطالعه بیشتر به بخش انتهایی این متن مراجعه کنید.
+
+#### نمای کلی (Overview)
+
+مفاهیم و اصطلاحات گوناگونی در حوزه امنیت وجود دارند که برای درک و بحث در مورد امنیت اپلیکیشن، اساسی
+هستند. مدیران امنیت و مهندسان امنیت با این اصطلاحات آشنا خواهند بود و تیم‌های توسعه نیز برای پیاده‌سازی
+اپلیکیشن‌های امن، به این درک نیاز دارند.
+
+#### امنیت در طراحی (Security by Design)
+
+امنیت نباید یک موضوع ثانویه یا یک افزودنی باشد. هنگام توسعه سیستم‌ها، باید با شناسایی نیازمندی‌های
+امنیتی مرتبط شروع کنید و آن‌ها را به عنوان بخشی جدایی‌ناپذیر از فرآیند کلی و طراحی سیستم در نظر بگیرید.
+کار را با ایجاد و اتخاذ اصول و سیاست‌های مرتبط به عنوان پایه‌ای برای طراحی خود آغاز کنید، سپس امنیت را
+در چرخه برنامه توسعه خود بگنجانید. همچنین به خاطر داشته باشید که سیستمی که می‌سازید به نگهداری نیز
+نیاز خواهد داشت و اپراتورهای سیستم باید بتوانند به طور امن سیستم را مدیریت کرده و حتی آن را از کار
+انداخته و از رده خارج کنند. بنابراین، با توسعه اصول و رویه‌های امن برای «مدیریت عملیاتی»[^1]،
+به عملیات امن متعهد باشید.
+
+#### امنیت در اولویت (Security by Default)
+
+«امنیت در اولویت» به این معناست که تنظیمات، امن‌ترین تنظیمات ممکن باشند. این لزوماً به معنای
+کاربرپسندترین تنظیمات نیست. بر اساس تحلیل ریسک و آزمون‌های کاربردپذیری، ارزیابی کنید که این تنظیمات
+باید چه باشند. در نتیجه، تصمیم‌گیری در مورد معنای دقیق آن بر عهده شماست. با این وجود، سیستم را طوری
+پیکربندی کنید که تنها کمترین عملکرد لازم را ارائه دهد و به طور مشخص استفاده از سایر عملکردها، پورت‌ها،
+پروتکل‌ها و یا سرویس‌ها را ممنوع و/یا محدود کند. همچنین، تنظیمات پیش‌فرض را مطابق با بهترین شیوه‌ها
+تا حد امکان محدودکننده پیکربندی کنید، بدون اینکه «پذیرش روانی» (Psychological acceptability) و
+«کاربردپذیری و مدیریت‌پذیری» (Usability and Manageability) سیستم به خطر بیفتد.
+
+#### عدم وجود تضمین امنیتی (No security guarantee)
+
+یکی از مهم‌ترین اصول امنیت نرم‌افزار این است که هیچ اپلیکیشن یا سیستمی به طور کامل و ۱۰۰٪ در برابر
+همه حملات مقاوم نیست. این ممکن است نقطه شروعی غیرمعمول و بدبینانه به نظر برسد، اما کاملا واقعی است؛
+با داشتن زمان و منابع کافی، هر سیستمی قابل نفوذ است. هدف از امنیت نرم‌افزار، «امنیت ۱۰۰٪» نیست،
+بلکه دشوار کردن نفوذ و کم‌ارزش کردن پاداش آن است، تا جایی که بازیگران مخرب برای بهره‌برداری به سراغ
+سیستم‌های دیگر بروند و این کار برایشان صرفه نداشته باشد.
+
+#### دفاع در عمق (Defense in Depth)
+
+[دفاع در عمق](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html#2-the-principle-of-defense-in-depth)
+که به آن دفاع لایه‌ای نیز گفته می‌شود، یک اصل امنیتی است که در آن، دفاع در برابر حمله توسط چندین کنترل
+امنیتی فراهم می‌شود. هدف این است که نقاط شکست کامل (single points of complete compromise) با گنجاندن
+یک سری یا چندین لایه از پادمان‌های امنیتی و اقدامات متقابل برای کاهش ریسک، حذف یا کاهش یابند.
+
+اگر یک لایه دفاعی ناکافی باشد، در صورتی که استراتژی‌های دفاعی متنوعی وجود داشته باشد، لایه دیگر ممکن
+است از یک نفوذ کامل جلوگیری کند و اگر آن لایه نیز دور زده شود، لایه بعدی ممکن است اکسپلویت را مسدود کند.
+
+#### حالت ایمن (Fail Safe)
+
+این یک اصل امنیتی است که هدف آن حفظ محرمانگی، یکپارچگی و در دسترس بودن (confidentiality, integrity and
+availability) هنگام شناسایی یک وضعیت خطا است. این وضعیت‌های خطا ممکن است نتیجه یک حمله باشند یا به دلیل
+نقص در طراحی یا پیاده‌سازی رخ دهند؛ در هر صورت، سیستم/اپلیکیشن‌ها باید به جای یک وضعیت ناامن، به یک
+وضعیت امن بازگردند.
+
+به عنوان مثال، تا زمانی که به یک موجودیت (entity) دسترسی صریح به یک شیء (object) داده نشده باشد، به
+طور پیش‌فرض باید دسترسی آن به آن شیء رد شود. این اغلب به عنوان «پیش‌فرض‌های حالت ایمن» (Fail Safe
+Defaults) یا «امنیت به صورت پیش‌فرض» (Secure by Default) توصیف می‌شود.
+
+در زمینه امنیت نرم‌افزار، اصطلاح «fail secure» معمولاً به جای «fail safe» به کار می‌رود که از اصطلاحات
+امنیت فیزیکی گرفته شده است. حالت ایمن همچنین به تاب‌آوری (resiliency) نرم‌افزار کمک می‌کند، به این
+ترتیب که سیستم/اپلیکیشن می‌تواند به سرعت پس از نقص‌های طراحی یا پیاده‌سازی، بهبود یابد.
+
+#### حداقل امتیاز (Least Privilege)
+
+یک اصل امنیتی که در آن به یک شخص یا فرآیند فقط حداقل سطح حقوق دسترسی (دسترسی امنیتی) که برای تکمیل
+یک عملیات محول شده ضروری است، داده می‌شود. این حق باید فقط برای حداقل زمان لازم برای تکمیل عملیات
+اعطا شود.
+
+این اصل با به حداقل رساندن توانایی یک مهاجم برای ارتقای امتیازات به صورت جانبی یا عمودی، به محدود
+کردن آسیب در هنگام نفوذ به سیستم کمک می‌کند. برای اعمال این
+[اصل حداقل امتیاز](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html#enforce-least-privileges)،
+باید سطح‌بندی (granularity) مناسبی از امتیازات و مجوزها ایجاد شود.
+
+#### بخش‌بندی (Compartmentalize)
+
+اصل حداقل امتیاز زمانی بهتر عمل می‌کند که اجازه دسترسی یک مدل «همه یا هیچ» نباشد. در عوض، دسترسی به
+اطلاعات را بر اساس «نیاز به دانستن» (need-to-know) برای انجام وظایف خاص، بخش‌بندی کنید. اصل بخش‌بندی
+به به حداقل رساندن تأثیر یک رخنه امنیتی در صورت وقوع یک تلاش موفق برای نفوذ کمک می‌کند، اما باید با
+اعتدال استفاده شود تا از غیرقابل مدیریت شدن سیستم جلوگیری شود. بنابراین، از اصل «صرفه‌جویی در سازوکار»
+(Economy of Mechanism) نیز پیروی کنید.
+
+#### تفکیک وظایف (Separation of Duties)
+
+تفکیک وظایف، که به عنوان
+[تفکیک امتیازات](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html#1-the-principle-of-least-privilege-and-separation-of-duties)
+نیز شناخته می‌شود، یک اصل امنیتی است که نیازمند آن است که تکمیل موفقیت‌آمیز یک وظیفه واحد، به دو یا
+چند شرط وابسته باشد که هر یک به تنهایی برای تکمیل آن وظیفه کافی نیستند.
+
+کاربردهای زیادی برای این اصل وجود دارد، به عنوان مثال محدود کردن آسیبی که یک کارمند ناراضی یا مخرب
+داخلی می‌تواند وارد کند، یا محدود کردن ارتقای امتیاز.
+
+#### صرفه‌جویی در سازوکار (Economy of Mechanism)
+
+این اصل که به «ساده نگه‌داشتن» (keep it simple) نیز معروف است، بیان می‌کند که اگر چندین پیاده‌سازی
+وجود دارد، باید ساده‌ترین و قابل فهم‌ترین پیاده‌سازی انتخاب شود.
+
+احتمال وجود آسیب‌پذیری‌ها با پیچیدگی طراحی معماری و کد نرم‌افزار افزایش می‌یابد و اگر دنبال کردن یا
+بازبینی کد دشوار باشد، این احتمال بیشتر هم می‌شود. با ساده و قابل فهم نگه داشتن طراحی و جزئیات پیاده‌سازی
+نرم‌افزار، سطح حمله (attack surface) آن کاهش می‌یابد.
+
+#### میانجی‌گری و بازنگری کامل (Complete Mediation)
+
+یک اصل امنیتی که تضمین می‌کند در درخواست‌های بعدی یک فاعل (subject) برای یک شیء (object)، مرجعیت
+(authority) دور زده نمی‌شود، و این کار را با بررسی مجوزها (حقوق و امتیازات) در هر بار درخواست برای
+آن شیء انجام می‌دهد.
+
+به عبارت دیگر، درخواست‌های دسترسی یک فاعل برای یک شیء هر بار به طور کامل میانجی‌گری می‌شوند، به طوری
+که تمام دسترسی‌ها به اشیاء باید بررسی شوند تا اطمینان حاصل شود که مجاز هستند.
+
+#### طراحی باز (Open Design)
+
+اصل امنیتی طراحی باز بیان می‌کند که جزئیات پیاده‌سازی یک طراحی باید مستقل از خود طراحی باشد، و به
+طراحی اجازه می‌دهد باز بماند در حالی که پیاده‌سازی می‌تواند مخفی نگه داشته شود. این در تضاد با «امنیت
+از طریق گمنامی» (security by obscurity) است که در آن امنیت نرم‌افزار به پنهان کردن خود طراحی بستگی دارد.
+
+هنگامی که نرم‌افزار با استفاده از مفهوم طراحی باز معماری می‌شود، بازبینی خود طراحی منجر به به خطر
+افتادن پادمان‌های امنیتی در نرم‌افزار نخواهد شد و این مورد مهمی محسوب می‌شود.
+
+#### حداقل سازوکار مشترک (Least Common Mechanism)
+
+اصل امنیتی حداقل سازوکار مشترک، اشتراک‌گذاری سازوکارهایی که بین بیش از یک کاربر یا فرآیند مشترک هستند
+را در صورتی که آن کاربران یا فرآیندها در سطوح امتیازی متفاوتی قرار دارند، ممنوع می‌کند. این امر هنگام
+دفاع در برابر ارتقای امتیاز اهمیت دارد و اجازه نمی‌دهد مهاجم دسترسی‌های خود را بالا برده و نفوذ را
+عمیق کند.
+
+#### پذیرش روانی (Psychological acceptability)
+
+یک اصل امنیتی که هدف آن به حداکثر رساندن استفاده و پذیرش قابلیت‌های امنیتی در نرم‌افزار است، و این
+کار را با اطمینان از اینکه قابلیت‌های امنیتی برای استفاده آسان و در عین حال برای کاربر شفاف هستند،
+انجام می‌دهد. سهولت استفاده و شفافیت، الزامات اساسی برای مؤثر بودن این اصل امنیتی هستند.
+
+کنترل‌های امنیتی نباید دسترسی به یک منبع را به طور قابل توجهی دشوارتر از زمانی کنند که آن کنترل امنیتی
+وجود نداشت. اگر یک کنترل امنیتی اصطکاک زیادی برای کاربران ایجاد کند، ممکن است آنها به دنبال راه‌هایی
+برای دور زدن آن کنترل بگردند و «درها را باز بگذارند».
+
+#### کاربردپذیری و مدیریت‌پذیری (Usability and Manageability)
+
+این اصلی است که با پذیرش روانی مرتبط است، اما فراتر از صرفاً پذیرش روانی درک‌شده رفته و شامل طراحی،
+پیاده‌سازی و عملیات کنترل‌های امنیتی نیز می‌شود. پیکربندی، مدیریت و یکپارچه‌سازی مؤلفه‌های امنیتی
+نباید بیش از حد پیچیده یا مبهم باشد. بنابراین، همیشه از استانداردهای باز برای قابلیت حمل و قابلیت
+همکاری استفاده کنید، از زبان مشترک در توسعه نیازمندی‌های امنیتی استفاده کنید، امنیت را طوری طراحی کنید
+که امکان پذیرش منظم فناوری جدید را فراهم کند، اطمینان حاصل کنید که یک فرآیند ارتقاء امن و منطقی
+وجود دارد، فعالیت‌های مدیریت امنیت را خودکار کنید و برای سهولت استفاده در عملیات تلاش کنید.
+
+#### ایمن‌سازی ضعیف‌ترین حلقه (Secure the Weakest Link)
+
+این اصل امنیتی بیان می‌کند که تاب‌آوری نرم‌افزار شما در برابر تلاش‌های هکرها، به شدت به حفاظت از
+ضعیف‌ترین مؤلفه‌های آن، چه کد، چه سرویس یا یک رابط کاربری، بستگی دارد. بنابراین، شناسایی ضعیف‌ترین
+مؤلفه و رسیدگی به جدی‌ترین ریسک در ابتدا، تا رسیدن به سطح قابل قبولی از ریسک، یک رویه امنیتی خوب
+محسوب می‌شود که در سطح اولیه حمله تلاش برای نفوذ را خنثی کند.
+
+#### بهره‌گیری از مؤلفه‌های موجود (Leveraging Existing Components)
+
+این یک اصل امنیتی است که بر اطمینان از عدم افزایش سطح حمله و عدم معرفی آسیب‌پذیری‌های جدید از طریق
+ترویج استفاده مجدد از مؤلفه‌ها، کد و قابلیت‌های نرم‌افزاری موجود تمرکز دارد.
+
+مؤلفه‌های موجود به احتمال زیاد امتحان شده و آزمایش شده‌اند و بنابراین امن‌تر هستند و همچنین باید
+پچ‌های امنیتی برای آنها در دسترس باشد. علاوه بر این، مؤلفه‌هایی که در جامعه منبع‌باز (open source)
+توسعه یافته‌اند، از مزیت «چشمان بسیار» بهره‌مند هستند و بنابراین احتمالاً حتی امن‌تر خواهند بود و در
+مواردی که مجبور به نوشتن کد یا سرویس دست‌نویس نیستید از آن استفاده نفرمایید.
+
+#### منابع (References)
+
+- مجموعه Cheat Sheetهای OWASP
+  - [Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
+  - [Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
+  - [Secure Product Design Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html)
+- کنترل‌های پیشگیرانه ۱۰گانه برتر OWASP
+  - [C5: Secure by Default Configurations](https://top10proactive.owasp.org/the-top-10/c5-secure-by-default/)
+- سایر موارد
+  - [Compartmentalization (information security)](https://en.wikipedia.org/wiki/Compartmentalization_(information_security)), (Wikipedia)
+  - [Least Functionality](https://csf.tools/reference/nist-sp-800-53/r5/cm/cm-7/), (NIST)
+  - [Security by Design](https://pubs.opengroup.org/security/o-esa/#_Toc291061712), (Open Group)
+  - [Usability and Manageability](https://pubs.opengroup.org/security/o-esa/#_Toc291061714), (Open Group)
+
+---
+
+راهنمای توسعه‌دهندگان OWASP یک تلاش جمعی است؛ اگر چیزی نیاز به تغییر دارد، لطفاً
+[یک issue ثبت کنید](https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/03-security-principles)
+یا [در GitHub ویرایش کنید](https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/03-security-principles.md).
+
+[^1]: [Operational Management](https://owaspsamm.org/model/operations/operational-management/), (SAMM)
\ No newline at end of file
diff --git a/docs/fa/02-foundations/04-crypto-principles.md b/docs/fa/02-foundations/04-crypto-principles.md
new file mode 100644
index 00000000..a0fea05f
--- /dev/null
+++ b/docs/fa/02-foundations/04-crypto-principles.md
@@ -0,0 +1,231 @@
+رمزنگاری برای حفظ محرمانگی (Confidentiality) و یکپارچگی (Integrity) اپلیکیشن‌ها و سیستم‌ها به شدت
+مهم و اساسی است. [مجموعه برگه‌های تقلب OWASP](https://cheatsheetseries.owasp.org/) کاربرد رمزنگاری را
+تشریح می‌کند که برخی از آن‌ها در بخش مطالعه بیشتر در انتهای این متن فهرست شده‌اند.
+
+#### نمای کلی
+
+این بخش مقدمه‌ای کوتاه بر رمزنگاری (که اغلب به سادگی «کریپتو یا سایفر» نامیده می‌شود) و اصطلاحات
+مورد استفاده در آن ارائه می‌دهد. رمزنگاری موضوعی بزرگ است و می‌تواند بسیار ریاضیاتی شود، اما خوشبختانه
+برای اکثر تیم‌های توسعه، درک کلی از مفاهیم کافی است. این درک عمومی، با راهنمایی معماران امنیت، باید
+به تیم توسعه اجازه دهد تا رمزنگاری را برای اپلیکیشن یا سیستم پیاده‌سازی کند.
+
+#### کاربردهای رمزنگاری
+
+اگرچه رمزنگاری در ابتدا عمدتاً به حوزه نظامی و دانشگاهی محدود بود، اما اکنون برای امن‌سازی اپلیکیشن‌های
+نرم‌افزاری همه‌گیر شده است. کاربردهای روزمره و رایج رمزنگاری شامل تلفن‌های همراه، رمزهای عبور، SSL VPNها،
+کارت‌های هوشمند و DVDها می‌شود. رمزنگاری در زندگی روزمره نفوذ کرده و توسط بسیاری از اپلیکیشن‌های وب به
+طور گسترده استفاده می‌شود.
+
+رمزنگاری یکی از موضوعات پیشرفته‌تر در امنیت اطلاعات است و درک آن به بیشترین میزان آموزش و تجربه نیاز دارد.
+پیاده‌سازی صحیح آن دشوار است زیرا رویکردهای زیادی برای رمزگذاری وجود دارد که هر کدام مزایا و معایبی
+دارند که باید توسط معمارانی که راهکارهای امنیتی را تدوین می‌کنند به طور کامل درک شوند.
+
+پیاده‌سازی صحیح و دقیق رمزنگاری برای کارایی آن بسیار حیاتی است. یک اشتباه کوچک در پیکربندی یا کدنویسی
+منجر به از بین رفتن بخش عمده‌ای از حفاظت شده و پیاده‌سازی رمزنگاری را بی‌فایده می‌کند.
+
+درک خوب از کریپتو برای تشخیص بین محصولات معتبر و محصولات بی‌ارزش (snake oil) لازم است. پیچیدگی ذاتی
+کریپتو باعث می‌شود به راحتی فریب ادعاهای خارق‌العاده فروشندگان درباره محصولاتشان را بخورید. معمولاً،
+این ادعاها شامل «یک پیشرفت شگرف در رمزنگاری»، «غیرقابل شکستن» یا ارائه امنیت «در سطح نظامی» هستند.
+اگر یک فروشنده بگوید «به ما اعتماد کنید، کارشناسان ما این را بررسی کرده‌اند»، به احتمال زیاد آن‌ها
+کارشناس نبوده‌اند!
+
+#### محرمانگی (Confidentiality)
+
+برای اهداف این بخش، محرمانگی به عنوان «عدم افشای غیرمجاز اطلاعات» تعریف می‌شود. رمزنگاری از طریق
+رمزگذاری داده‌ها در حالت سکون (data at rest) یا داده‌ها در حال انتقال (data in transit) به این موضوع
+می‌پردازد و اطلاعات را در برابر همه کسانی که کلید رمزگشایی را ندارند، محافظت می‌کند. از هش‌های
+رمزنگاری (هش‌های امن و یک‌طرفه) برای جلوگیری از افشای رمزهای عبور استفاده می‌شود.
+
+#### احراز هویت (Authentication)
+
+احراز هویت فرآیند تأیید ادعای یک فاعل (subject) مبنی بر اینکه او همان کسی است که می‌گوید، از طریق
+شواهد تأییدکننده ارائه شده است. رمزنگاری در احراز هویت نقش محوری دارد:
+
+1.  برای محافظت از شواهد تأییدکننده ارائه شده (به عنوان مثال، هش کردن رمزهای عبور برای ذخیره‌سازی بعدی).
+2.  در پروتکل‌های احراز هویت که اغلب از رمزنگاری برای احراز هویت مستقیم موجودیت‌ها یا تبادل امن اعتبارنامه‌ها
+    استفاده می‌کنند.
+3.  برای تأیید هویت یک یا هر دو طرف در تبادل پیام‌ها, به عنوان مثال تأیید هویت در امنیت لایه انتقال (TLS).
+
+OpenID Connect به طور گسترده به عنوان یک لایه هویتی بر روی پروتکل OAuth 2.0 استفاده می‌شود. به
+[برگه تقلب پروتکل OAuth 2.0](https://cheatsheetseries.owasp.org/cheatsheets/OAuth_2.0_Cheat_Sheet.html) مراجعه کنید.
+
+#### یکپارچگی (Integrity)
+
+یکپارچگی تضمین می‌کند که حتی کاربران مجاز نیز هیچ‌گونه تغییر تصادفی یا مخربی در اطلاعات ایجاد نکرده‌اند.
+می‌توان از رمزنگاری برای جلوگیری از دستکاری به وسیله کدهای احراز هویت پیام (MACs) یا امضاهای دیجیتال
+استفاده کرد.
+
+اصطلاح «اصالت پیام» (message authenticity) به تضمین یکپارچگی اطلاعات، اغلب با استفاده از رمزنگاری
+متقارن و کلیدهای مشترک، اشاره دارد اما هویت فرستنده را احراز نمی‌کند.
+
+اصطلاح «رمزنگاری احراز هویت شده» (authenticated encryption) نیز یکپارچگی اطلاعات را تضمین می‌کند و اگر
+از رمزنگاری نامتقارن استفاده شود، می‌تواند فرستنده را نیز احراز هویت کند.
+
+#### عدم انکار (Non-repudiation)
+
+عدم انکار فرستنده تضمین می‌کند که شخصی که پیامی را ارسال می‌کند، نتواند بعداً ارسال آن را انکار کند.
+عدم انکار گیرنده به این معناست که گیرنده یک پیام نتواند دریافت آن را انکار کند. می‌توان از رمزنگاری
+برای ارائه عدم انکار از طریق پیام‌ها یا پاسخ‌های غیرقابل جعل استفاده کرد.
+
+عدم انکار برای تبادلات مالی، تجارت الکترونیک و قراردادها مفید است. این کار می‌تواند با امضای دیجیتالی
+یک رکورد تراکنش منحصر به فرد توسط فرستنده یا گیرنده انجام شود.
+
+#### گواهی‌دهی (Attestation)
+
+گواهی‌دهی عمل «شهادت دادن» یا تأیید چیزی برای یک کاربرد یا هدف خاص است. گواهی‌دهی به طور کلی در زمینه
+ماژول پلتفرم مورد اعتماد (TPM)، مدیریت حقوق دیجیتال (DRM) و بوت امن UEFI مورد بحث قرار می‌گیرد.
+
+به عنوان مثال، مدیریت حقوق دیجیتال به گواهی این موضوع علاقه‌مند است که دستگاه یا سیستم شما با یک در پشتی
+(back-door) که به کسی اجازه کپی غیرقانونی محتوای محافظت‌شده با DRM را می‌دهد، به خطر نیفتاده باشد.
+
+می‌توان از رمزنگاری برای ارائه زنجیره‌ای از شواهد مبنی بر اینکه همه چیز همانطور که انتظار می‌رود است،
+تا به یک چالشگر ثابت شود که همه چیز مطابق با انتظارات اوست. به عنوان مثال، می‌توان از گواهی‌دهی از
+راه دور برای اثبات به یک چالشگر استفاده کرد که شما واقعاً در حال اجرای نرم‌افزاری هستید که ادعا
+می‌کنید. اغلب گواهی‌دهی با ارائه زنجیره‌ای از امضاهای دیجیتال که با یک بوت لودر مورد اعتماد (امضا
+شده دیجیتالی) شروع می‌شود، انجام می‌گردد.
+
+#### هش‌های رمزنگاری
+
+هش‌های رمزنگاری که به آن‌ها خلاصه‌ی پیام (message digests) نیز گفته می‌شود، توابعی هستند که رشته‌های
+بیتی با طول دلخواه را به یک رشته بیتی با طول ثابت به نام «مقدار هش» یا «مقدار خلاصه» نگاشت می‌کنند.
+این توابع هش، نگاشت‌های چند به یک هستند که توابع فشرده‌سازی محسوب می‌شوند.
+
+توابع هش رمزنگاری برای تأمین یکپارچگی داده‌ها (یعنی شناسایی دستکاری عمدی داده‌ها)، ذخیره رمزهای عبور
+یا عبارات عبور و ارائه امضاهای دیجیتال به روشی کارآمدتر از رمزهای نامتقارن استفاده می‌شوند. توابع هش
+رمزنگاری همچنین برای گسترش مقدار نسبتاً کوچکی از آنتروپی استفاده می‌شوند تا بتوان مولدهای اعداد تصادفی
+امن ساخت.
+
+هنگامی که برای تأمین یکپارچگی داده‌ها استفاده می‌شوند، توابع رمزنگاری دو نوع یکپارچگی را فراهم می‌کنند:
+هش‌های کلیددار که اغلب «کدهای احراز هویت پیام» نامیده می‌شوند و هش‌های بدون کلید که «کدهای یکپارچگی
+پیام» نامیده می‌شوند.
+
+#### رمزها (Ciphers)
+
+رمز (Cipher) الگوریتمی است که رمزگذاری یا رمزگشایی را انجام می‌دهد. رمزهای مدرن را می‌توان به چند
+روش مختلف دسته‌بندی کرد. رایج‌ترین تمایز بین آنها عبارتند از:
+
+* اینکه آیا روی تعداد ثابتی از بیت‌ها کار می‌کنند (رمزهای قالبی یا block ciphers) یا روی یک جریان
+  پیوسته از بیت‌ها (رمزهای جریانی یا stream ciphers).
+* اینکه آیا از کلید یکسانی برای رمزگذاری و رمزگشایی استفاده می‌شود (رمزهای متقارن یا symmetric ciphers)
+  یا از کلیدهای جداگانه برای رمزگذاری و رمزگشایی (رمزهای نامتقارن یا asymmetric ciphers).
+
+#### رمزهای متقارن (Symmetric Ciphers)
+
+رمزهای متقارن با استفاده از یک کلید یکسان، رمزگذاری و رمزگشایی می‌کنند. این بدان معناست که اگر یک طرف
+داده‌ها را رمزگذاری کند و طرف دیگر باید آن را رمزگشایی کند، آن دو طرف باید یک کلید مشترک داشته باشند.
+
+رمزهای متقارن دو نوع اصلی دارند:
+
+1.  رمزهای قالبی (Block ciphers)، که هر بار روی یک بلوک از کاراکترها (معمولاً ۸ یا ۱۶ اکتت) عمل می‌کنند.
+    نمونه‌ای از رمز قالبی، AES است.
+2.  رمزهای جریانی (Stream ciphers)، که هر بار روی یک بیت (یا گاهی یک بایت) عمل می‌کنند. نمونه‌هایی از
+    رمزهای جریانی RC4 (معروف به ARC4) و Salsa20 هستند.
+
+توجه داشته باشید که تمام رمزهای قالبی با انتخاب حالت رمز مناسب می‌توانند در «حالت جریانی» نیز عمل کنند.
+
+#### حالت‌های رمز (Cipher Modes)
+
+رمزهای قالبی می‌توانند در حالت‌های عملیاتی مختلفی به نام «حالت‌های رمز» کار کنند. این حالت رمز به
+صورت الگوریتمی نحوه عملکرد یک رمز را برای اعمال مکرر مکانیزم رمزگذاری یا رمزگشایی خود بر روی یک
+بلوک رمز معین توصیف می‌کند. حالت‌های رمز مهم هستند زیرا تأثیر بسیار زیادی بر محرمانگی و اصالت پیام
+متن‌های رمز شده حاصل دارند.
+
+تقریباً تمام کتابخانه‌های رمزنگاری از چهار حالت رمز اصلی DES یعنی ECB، CBC (زنجیره‌سازی بلوک رمز)،
+OFB (بازخورد خروجی) و CFB (بازخورد رمز) پشتیبانی می‌کنند. بسیاری نیز از حالت CTR (شمارنده)
+پشتیبانی می‌کنند.
+
+#### بردار اولیه (Initialization vector)
+
+بردار اولیه رمزنگاری (IV) یک ورودی با اندازه ثابت برای تابع اولیه رمزگذاری / رمزگشایی یک رمز قالبی است.
+توصیه می‌شود (و در بسیاری موارد، الزامی است) که IV تصادفی یا حداقل شبه تصادفی باشد.
+
+#### ایجاد فاصله (Padding)
+
+رمزهای قالبی، به جز زمانی که در حالت جریانی کار می‌کنند، معمولاً روی بلوک‌هایی با اندازه ثابت عمل
+می‌کنند. این رمزهای قالبی باید بتوانند روی پیام‌هایی با هر اندازه‌ای نیز کار کنند، نه فقط آنهایی که
+مضرب صحیحی از اندازه بلوک رمز هستند، و بنابراین می‌توان پیام را فاصله‌گذاری (padded) کرد تا در
+بلوک بعدی با اندازه ثابت قرار گیرد.
+
+#### رمزهای نامتقارن (Asymmetric ciphers)
+
+رمزهای نامتقارن با دو کلید متفاوت رمزگذاری و رمزگشایی می‌کنند. یک کلید معمولاً به عنوان کلید خصوصی و
+دیگری به عنوان کلید عمومی تعیین می‌شود. به طور کلی، کلید عمومی به طور گسترده به اشتراک گذاشته می‌شود
+و کلید خصوصی امن نگه داشته می‌شود.
+
+رمزهای نامتقارن چندین برابر کندتر از رمزهای متقارن هستند. به همین دلیل، آنها اغلب در سیستم‌های رمزنگاری
+ترکیبی (hybrid cryptosystems) که رمزهای نامتقارن و متقارن را ترکیب می‌کنند، استفاده می‌شوند. در چنین
+سیستم‌های ترکیبی، یک کلید جلسه متقارن تصادفی تولید می‌شود که فقط برای مدت زمان ارتباط رمزگذاری شده
+استفاده می‌شود. سپس این کلید جلسه تصادفی با استفاده از یک رمز نامتقارن و کلید خصوصی گیرنده رمزگذاری
+می‌شود. داده‌های متنی ساده (plaintext) خود با کلید جلسه رمزگذاری می‌شوند. سپس کل بسته (کلید جلسه
+رمزگذاری شده و پیام رمزگذاری شده) با هم ارسال می‌شود.
+
+هر دو TLS و S/MIME سیستم‌های رمزنگاری رایجی هستند که از رمزنگاری ترکیبی استفاده می‌کنند.
+
+#### امضای دیجیتال (Digital signature)
+
+امضاهای دیجیتال یک رشته داده منحصر به فرد رمزنگاری شده هستند که برای تضمین یکپارچگی داده‌ها، اثبات
+اصالت یک پیام دیجیتال و مرتبط کردن یک پیام ورودی با یک موجودیت مبدأ استفاده می‌شوند. الگوریتم تولید
+امضای دیجیتال یک الگوریتم قوی رمزنگاری است که برای تولید امضای دیجیتال استفاده می‌شود.
+
+#### پروتکل توافق کلید (Key agreement protocol)
+
+پروتکل‌های توافق کلید، پروتکل‌هایی هستند که به وسیله آنها N طرف (معمولاً دو طرف) می‌توانند بر روی
+یک کلید مشترک بدون تبادل واقعی کلید به توافق برسند. در صورت طراحی و پیاده‌سازی صحیح، پروتکل‌های توافق
+کلید از یادگیری کلید توسط دشمنان یا تحمیل انتخاب کلید خودشان بر طرف‌های شرکت‌کننده جلوگیری می‌کنند.
+
+#### رمزگذاری در سطح اپلیکیشن (Application level encryption)
+
+رمزگذاری در سطح اپلیکیشن به رمزگذاری‌ای اطلاق می‌شود که بخشی از خود اپلیکیشن در نظر گرفته می‌شود؛ این
+موضوع هیچ چیزی را در مورد اینکه رمزگذاری واقعاً در کجای کد اپلیکیشن انجام می‌شود، بیان نمی‌کند.
+
+#### استخراج کلید (Key derivation)
+
+تابع استخراج کلید (KDF) یک الگوریتم قطعی برای استخراج یک کلید با اندازه معین از یک مقدار مخفی است.
+اگر دو طرف از یک مقدار مخفی مشترک و یک KDF یکسان استفاده کنند، باید همیشه دقیقاً همان کلید را استخراج کنند.
+
+#### پوشش کلید (Key wrapping)
+
+پوشش کلید، ساختاری است که با رمزهای متقارن برای محافظت از مواد کلید رمزنگاری از طریق رمزگذاری آن به
+روشی خاص استفاده می‌شود. الگوریتم‌های پوشش کلید برای محافظت از کلیدها در حین نگهداری در حافظه غیرقابل
+اعتماد یا هنگام انتقال کلیدها از طریق شبکه‌های ارتباطی ناامن در نظر گرفته شده‌اند.
+
+#### الگوریتم‌های تبادل کلید (Key exchange algorithms)
+
+الگوریتم‌های تبادل کلید (که به آنها الگوریتم‌های ایجاد کلید نیز گفته می‌شود) پروتکل‌هایی هستند که برای
+تبادل کلیدهای رمزنگاری مخفی بین فرستنده و گیرنده به روشی که محدودیت‌های امنیتی خاصی را برآورده کند،
+استفاده می‌شوند. الگوریتم‌های تبادل کلید سعی در حل مشکل به اشتراک‌گذاری امن یک کلید مخفی مشترک با دو
+طرف از طریق یک کانال ارتباطی ناامن به گونه‌ای دارند که هیچ طرف دیگری نتواند به نسخه‌ای از کلید مخفی
+دسترسی پیدا کند.
+
+آشناترین الگوریتم تبادل کلید، تبادل کلید دیفی-هلمن است. الگوریتم‌های تبادل کلید احراز هویت شده با
+رمز عبور نیز وجود دارند. تبادل کلید RSA با استفاده از PKI یا وب‌های اعتماد یا سرورهای کلید مورد
+اعتماد نیز به طور رایج استفاده می‌شوند.
+
+#### پروتکل‌های انتقال کلید (Key transport protocols)
+
+پروتکل‌های انتقال کلید پروتکل‌هایی هستند که در آنها یک طرف کلید را تولید کرده و آن را به طور امن برای
+گیرنده(ها) ارسال می‌کند.
+
+#### پروتکل‌های توافق کلید (Key agreement protocols)
+
+پروتکل‌های توافق کلید پروتکل‌هایی هستند که به وسیله آنها N طرف (معمولاً دو طرف) می‌توانند بر روی یک
+کلید مشترک به توافق برسند در حالی که همه طرف‌ها در مقدار کلید مشارکت دارند. این پروتکل‌ها از یادگیری
+کلید توسط دشمنان یا تحمیل انتخاب کلید خودشان بر طرف‌های شرکت‌کننده جلوگیری می‌کنند.
+
+#### منابع (References)
+
+* مجموعه Cheat Sheetهای OWASP
+  * [Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
+  * [Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
+  * [Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)
+  * [Key Management](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html)
+  * [OAuth 2.0 Protocol](https://cheatsheetseries.owasp.org/cheatsheets/OAuth_2.0_Cheat_Sheet.html)
+  * [SAML Security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html)
+  * [Secure Product Design](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html)
+  * [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html)
+
+---
+
+راهنمای توسعه‌دهندگان OWASP یک تلاش جمعی است؛ اگر چیزی نیاز به تغییر دارد، لطفاً
+[یک issue ثبت کنید](https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/04-crypto-principles)
+یا [در GitHub ویرایش کنید](https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/04-crypto-principles.md).
\ No newline at end of file
diff --git a/docs/fa/02-foundations/05-top-ten.md b/docs/fa/02-foundations/05-top-ten.md
new file mode 100644
index 00000000..fbb5c880
--- /dev/null
+++ b/docs/fa/02-foundations/05-top-ten.md
@@ -0,0 +1,212 @@
+[![Top 10 logo](../../assets/images/logos/top10.png "OWASP Top 10")](https://owasp.org/www-project-top-ten/){ align=right width=180 }
+
+OWASP Top Ten یک فهرست بسیار شناخته‌شده از خطرات امنیتی اپلیکیشن‌های وب است و توسط مدل تضمین تکامل
+نرم‌افزار OWASP ([SAMM][samm]) در بخش آموزش و راهنمایی (Education & Guidance) در زیرمجموعه عملکرد
+تجاری حاکمیت (Governance) گنجانده شده است.
+
+#### نمای کلی
+
+پروژه [۱۰ ریسک امنیتی برتر اپلیکیشن‌های وب OWASP](https://owasp.org/www-project-top-ten/) احتمالاً
+شناخته‌شده‌ترین مفهوم امنیتی در جامعه امنیت است که اندکی پس از انتشارش در سال ۲۰۰۳ به پذیرش و شهرت
+گسترده‌ای دست یافت. این فهرست که اغلب فقط «OWASP Top Ten» نامیده می‌شود، لیستی است که مهم‌ترین تهدیدات
+برای اپلیکیشن‌های وب را شناسایی کرده و به دنبال رتبه‌بندی آن‌ها بر اساس اهمیت و شدت است.
+
+این فهرست با گذشت زمان تغییر کرده است؛ با تغییر فناوری‌ها، برخی از انواع تهدیدات به مشکل بزرگ‌تری برای
+اپلیکیشن‌های وب تبدیل شده و برخی دیگر به ریسک کمتری مبدل شده‌اند. [آخرین نسخه](https://owasp.org/Top10/)
+در سال ۲۰۲۱ منتشر شد و هر دسته در ادامه به طور خلاصه شرح داده شده است.
+
+توجه داشته باشید که پروژه‌های مختلف «OWASP Top Ten» وجود دارد، به عنوان مثال «۱۰ مورد برتر OWASP برای
+اپلیکیشن‌های مدل‌های زبان بزرگ»، بنابراین برای جلوگیری از سردرگمی، هنگام ارجاع به این لیست‌ها باید به
+زمینه (context) توجه شود.
+
+#### A01:2021 کنترل دسترسی ناقص (Broken Access Control)
+
+کنترل دسترسی شامل استفاده از مکانیسم‌های حفاظتی است که می‌توان آن‌ها را به دسته‌های زیر طبقه‌بندی کرد:
+
+- احراز هویت (Authentication): اثبات هویت یک عامل.
+- مجوزدهی (Authorization): اطمینان از اینکه یک عامل معین می‌تواند به یک منبع دسترسی داشته باشد.
+- پایش (Accountability): رصد و ردیابی فعالیت‌هایی که انجام شده است.
+
+کنترل دسترسی ناقص زمانی رخ می‌دهد که محصول، دسترسی یک عامل غیرمجاز یا مخرب به یک منبع را محدود نمی‌کند
+یا به اشتباه محدود می‌کند.
+
+هنگامی که یک کنترل امنیتی شکست می‌خورد یا اعمال نمی‌شود، مهاجمان می‌توانند با به دست آوردن امتیاز دسترسی،
+خواندن اطلاعات حساس، اجرای دستورات، فرار از شناسایی و غیره، امنیت محصول را به خطر بیندازند.
+
+کنترل دسترسی ناقص می‌تواند اشکال مختلفی داشته باشد، مانند پیمایش مسیر (path traversal) یا ارتقاء امتیاز
+دسترسی‌های امنیتی (elevation of privilege)، بنابراین به هر دو منبع
+[شمارش ضعف‌های متداول CWE-284](https://cwe.mitre.org/data/definitions/284.html) و
+[A01 کنترل دسترسی ناقص](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) مراجعه کرده و همچنین
+[Cheat Sheetهای مختلف OWASP](https://cheatsheetseries.owasp.org/IndexTopTen.html#a012021-broken-access-control)
+مربوط به کنترل‌های دسترسی را دنبال کنید.
+
+#### A02:2021 نقص‌های رمزنگاری (Cryptographic Failures)
+
+با ارجاع به [OWASP Top 10 A02:2021](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/)، داده‌های
+حساس باید هنگام ذخیره‌سازی (at rest) و انتقال (in transit) محافظت شوند.
+
+نقص‌های رمزنگاری زمانی رخ می‌دهند که کنترل امنیتی رمزنگاری شکسته شده یا اعمال نشده باشد و داده‌ها در
+معرض عوامل غیرمجاز - چه مخرب و چه غیرمخرب - قرار گیرند.
+
+مهم است که داده‌ها هم در حالت سکون، یعنی زمانی که در بخشی از حافظه ذخیره شده‌اند، و هم در حالت انتقال،
+مانند زمانی که از طریق یک کانال ارتباطی منتقل یا در حال تبدیل هستند، محافظت شوند. یک مثال خوب از
+حفاظت در حین تبدیل داده توسط
+[A02 نقص‌های رمزنگاری](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/) ارائه شده است که در
+آن داده‌های حساس به درستی در یک پایگاه داده رمزگذاری شده‌اند، اما تابع صدور (export) به طور خودکار
+داده‌ها را رمزگشایی می‌کند که منجر به افشای داده‌های حساس می‌شود.
+
+نقص‌های کریپتو می‌توانند اشکال مختلفی داشته باشند و ممکن است ظریف باشند - یک کنترل امنیتی که امن به
+نظر می‌رسد ممکن است به راحتی شکسته شود. برای پیاده‌سازی کنترل‌های اولیه رمزنگاری،
+[Cheat Sheetهای کریپتو OWASP](https://cheatsheetseries.owasp.org/IndexTopTen.html#a022021-cryptographic-failures)
+را دنبال کنید و در نظر داشته باشید که یک ممیزی رمزنگاری را نیز اجرا کنید.
+
+#### A03:2021 تزریق (Injection)
+
+فقدان اعتبارسنجی و پاک‌سازی ورودی‌ها می‌تواند به اکسپلویت‌های تزریق منجر شود و این ریسک از زمان انتشار
+اولین نسخه OWASP Top Ten در سال ۲۰۰۳ یک ویژگی ثابت در این فهرست بوده است.
+
+این آسیب‌پذیری‌ها زمانی رخ می‌دهند که داده‌های متخاصم مستقیماً در اپلیکیشن استفاده شوند و می‌توانند
+منجر به استفاده از داده‌های مخرب برای منحرف کردن اپلیکیشن شوند؛ برای توضیحات بیشتر به
+[A03 Injection](https://owasp.org/Top10/A03_2021-Injection/) مراجعه کنید.
+
+کنترل امنیتی واضح است: تمام ورودی‌ها از منابع غیرقابل اعتماد باید پاک‌سازی و اعتبارسنجی شوند.
+
+برای انواع مختلف ورودی‌ها و کنترل‌های آن‌ها به
+[Cheat Sheetهای تزریق](https://cheatsheetseries.owasp.org/IndexTopTen.html#a032021-injection) مراجعه کنید.
+
+#### A04:2021 طراحی ناامن (Insecure Design)
+
+مهم است که امنیت از ابتدا در اپلیکیشن‌ها گنجانده شود و نه به عنوان یک فکر ثانویه به آن اضافه گردد.
+دسته‌بندی [A04 طراحی ناامن](https://owasp.org/Top10/A04_2021-Insecure_Design/) این موضوع را به رسمیت
+می‌شناسد و توصیه می‌کند که استفاده از مدل‌سازی تهدید (threat modeling)، الگوهای طراحی امن و معماری‌های
+مرجع باید در فعالیت‌های طراحی و معماری اپلیکیشن گنجانده شود.
+
+در عمل، این شامل ایجاد یک چرخه عمر توسعه امن است که شناسایی نیازمندی‌های امنیتی، استفاده دوره‌ای از
+مدل‌سازی تهدید و در نظر گرفتن کتابخانه‌ها و فریمورک‌های امن موجود را تشویق می‌کند. این دسته در نسخه
+۲۰۲۱ معرفی شد و در حال حاضر Cheat Sheetهای پشتیبان آن فقط
+[مدل‌سازی تهدید](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html)
+را پوشش می‌دهند؛ انتظار می‌رود با جا افتادن بیشتر این دسته، اطلاعات پشتیبانی بیشتری در دسترس قرار گیرد.
+
+#### A05:2021 پیکربندی نادرست امنیتی (Security Misconfiguration)
+
+سیستم‌ها و اپلیکیشن‌های بزرگ می‌توانند قابل پیکربندی باشند و این پیکربندی اغلب برای امن‌سازی
+سیستم/اپلیکیشن استفاده می‌شود.
+
+اگر این پیکربندی به اشتباه اعمال شود، ممکن است اپلیکیشن دیگر امن نباشد و در عوض در برابر اکسپلویت‌های
+شناخته‌شده آسیب‌پذیر شود.
+
+صفحه [A05 Security Misconfiguration](https://owasp.org/Top10/A05_2021-Security_Misconfiguration/)
+یک مثال رایج از پیکربندی نادرست را شامل می‌شود که در آن حساب‌های کاربری پیش‌فرض و رمزهای عبور آن‌ها
+همچنان فعال و بدون تغییر باقی مانده‌اند.
+
+این رمزهای عبور و حساب‌ها معمولاً به خوبی شناخته شده‌اند و راهی آسان برای عوامل مخرب جهت نفوذ به
+اپلیکیشن‌ها فراهم می‌کنند.
+
+هر دو منبع [OWASP Top 10 A05:2021](https://owasp.org/Top10/A05_2021-Security_Misconfiguration/) و
+[Cheat Sheetهای OWASP](https://cheatsheetseries.owasp.org/IndexTopTen.html#a052021-security-misconfiguration)
+مرتبط، استراتژی‌هایی را برای ایجاد یک فرآیند پیکربندی امنیتی هماهنگ و تکرارپذیر برای اپلیکیشن ارائه
+می‌دهند تا پیکربندی‌های نادرست به حداقل برسد.
+
+#### A06:2021 مؤلفه‌های آسیب‌پذیر و قدیمی (Vulnerable and Outdated Components)
+
+شاید یکی از ساده‌ترین و مؤثرترین فعالیت‌های امنیتی، به‌روز نگه داشتن تمام وابستگی‌های نرم‌افزاری
+شخص ثالث باشد.
+
+اگر یک وابستگی آسیب‌پذیر توسط یک عامل مخرب در مرحله شناسایی (reconnaissance) یک حمله شناسایی شود،
+پایگاه‌های داده‌ای مانند [Exploit Database](https://www.exploit-db.com/) وجود دارند که شرح هر اکسپلویت
+را ارائه می‌دهند. این پایگاه‌های داده همچنین می‌توانند اسکریپت‌ها و تکنیک‌های آماده‌ای برای حمله به
+یک آسیب‌پذیری خاص فراهم کنند، که بهره‌برداری از وابستگی‌های نرم‌افزاری شخص ثالث آسیب‌پذیر را آسان می‌سازد.
+
+ریسک [A06 مؤلفه‌های آسیب‌پذیر و قدیمی](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)
+بر اهمیت این فعالیت تأکید می‌کند و توصیه می‌کند که اصلاحات و ارتقاء پلتفرم، فریمورک‌ها و وابستگی‌های
+زیربنایی بر اساس ارزیابی ریسک و به «شیوه‌ای به موقع» انجام شود. ابزارهای متعددی می‌توانند برای تجزیه
+و تحلیل وابستگی‌ها و شناسایی آسیب‌پذیری‌ها استفاده شوند؛ برای این ابزارها به
+[Cheat Sheetها](https://cheatsheetseries.owasp.org/IndexTopTen.html#a062021-vulnerable-and-outdated-components)
+مراجعه کنید.
+
+#### A07:2021 نقص‌های شناسایی و احراز هویت (Identification and Authentication Failures)
+
+تأیید هویت کاربر، احراز هویت و مدیریت جلسه برای محافظت از سیستم یا اپلیکیشن در برابر حملات مرتبط با
+احراز هویت حیاتی است. با ارجاع به ریسک
+[A07 نقص‌های شناسایی و احراز هویت](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/)،
+مجوزدهی می‌تواند به روش‌های مختلفی با شکست مواجه شود که اغلب شامل سایر ریسک‌های OWASP Top Ten است:
+
+- کنترل‌های دسترسی ناقص (A01)
+- نقص رمزنگاری (A02)
+- رمزهای عبور پیش‌فرض (A05)
+- کتابخانه‌های قدیمی (A06)
+
+برای چندین رویه خوب که برای مجوزدهی امن لازم است، به
+[Cheat Sheetها](https://cheatsheetseries.owasp.org/IndexTopTen.html#a072021-identification-and-authentication-failures)
+مراجعه کنید.
+
+همچنین تأمین‌کنندگان شخص ثالثی برای مدیریت هویت و دسترسی (IAM) وجود دارند که این را به عنوان یک
+سرویس ارائه می‌دهند؛ هزینه و فایده استفاده از این تأمین‌کنندگان را در نظر بگیرید.
+
+#### A08:2021 نقص‌های یکپارچگی نرم‌افزار و داده (Software and Data Integrity Failures)
+
+نقص‌های یکپارچگی نرم‌افزار و داده به کد و زیرساختی مربوط می‌شود که در برابر نقض یکپارچگی محافظت نمی‌کنند.
+
+این یک دسته‌بندی گسترده است که به عنوان مثال
+[حملات زنجیره تأمین](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html)،
+به‌روزرسانی خودکار به خطر افتاده و استفاده از مؤلفه‌های غیرقابل اعتماد را توصیف می‌کند.
+
+[A08 Software and Data Integrity Failures](https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/)
+یک دسته جدید بود که در سال ۲۰۲۱ معرفی شد، بنابراین اطلاعات کمی از
+[Cheat Sheetها](https://cheatsheetseries.owasp.org/IndexTopTen.html#a082021-software-and-data-integrity-failures)
+در دسترس است، اما با توجه به اهمیت این تهدید، این وضعیت قطعاً تغییر خواهد کرد.
+
+#### A09:2021 نقص‌های ثبت وقایع و نظارت امنیتی (Security Logging and Monitoring Failures)
+
+ثبت وقایع و نظارت به شناسایی، تشدید و پاسخ به نفوذهای فعال کمک می‌کند؛ بدون آن، نفوذها شناسایی نخواهند شد.
+[A09 نقص‌های ثبت وقایع و نظارت امنیتی](https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/)
+تکنیک‌های مختلف ثبت وقایع و نظارت را فهرست می‌کند که باید آشنا باشند، اما همچنین موارد دیگری که ممکن
+است چندان رایج نباشند را نیز شامل می‌شود؛ به عنوان مثال، نظارت بر زنجیره تأمین DevOps ممکن است به همان
+اندازه نظارت بر اپلیکیشن یا سیستم مهم باشد.
+
+[Cheat Sheetها](https://cheatsheetseries.owasp.org/IndexTopTen.html#a092021-security-logging-and-monitoring-failures)
+راهنمایی‌هایی در مورد ثبت وقایع کافی ارائه می‌دهند و همچنین یک واژگان مشترک برای ثبت وقایع فراهم می‌کنند.
+هدف از این واژگان مشترک، ارائه ثبت وقایعی است که از مجموعه‌ای مشترک از اصطلاحات، فرمت‌ها و کلمات کلیدی
+استفاده می‌کند؛ و این امر نظارت، تحلیل و هشداردهی را آسان‌تر می‌کند.
+
+#### A10:2021 جعل درخواست سمت سرور (Server-Side Request Forgery)
+
+با ارجاع به [A10 جعل درخواست سمت سرور (SSRF)](https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/)،
+این آسیب‌پذیری‌ها می‌توانند هر زمانی که یک اپلیکیشن وب در حال واکشی یک منبع از راه دور بدون اعتبارسنجی
+URL ارائه‌شده توسط کاربر باشد، رخ دهند. این اکسپلویت‌ها به یک مهاجم اجازه می‌دهند تا اپلیکیشن را وادار
+به ارسال یک درخواست دستکاری‌شده به یک مقصد غیرمنتظره کند، حتی زمانی که توسط یک فایروال، VPN یا نوع دیگری
+از لیست کنترل دسترسی شبکه محافظت می‌شود. واکشی یک URL به یک سناریوی رایج برای اپلیکیشن‌های وب مدرن تبدیل
+شده و در نتیجه، وقوع SSRF به ویژه برای
+[سرویس‌های ابری](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html)
+و معماری‌های پیچیده‌تر اپلیکیشن در حال افزایش است.
+
+این یک دسته جدید است که در سال ۲۰۲۱ با یک
+[Cheat Sheet](https://cheatsheetseries.owasp.org/IndexTopTen.html#a102021-server-side-request-forgery-ssrf)
+(در حال حاضر) که به SSRF می‌پردازد، معرفی شد.
+
+#### لیست‌های ده مورد برتر OWASP
+
+پروژه‌های مختلف «۱۰ مورد برتر» توسط OWASP ایجاد شده‌اند که بسته به زمینه، ممکن است به آنها نیز «OWASP Top 10»
+گفته شود. در اینجا لیستی از پروژه‌های پایدار «OWASP Top 10» آمده است:
+
+- [۱۰ مورد برتر امنیت API](https://owasp.org/API-Security/)
+- [۱۰ مورد برتر امنیت داده](https://owasp.org/www-project-data-security-top-10/)
+- [۱۰ مورد برتر Low-Code/No-Code](https://owasp.org/www-project-top-10-low-code-no-code-security-risks/)
+- [۱۰ مورد برتر موبایل](https://owasp.org/www-project-mobile-top-10/)
+- [۱۰ مورد برتر بدون سرور (Serverless)](https://owasp.org/www-project-serverless-top-10/)
+- [۱۰ ریسک امنیتی برتر CI/CD](https://owasp.org/www-project-top-10-ci-cd-security-risks/)
+- [۱۰ مورد برتر برای اپلیکیشن‌های مدل‌های زبان بزرگ](https://owasp.org/www-project-top-10-for-large-language-model-applications/)
+- [۱۰ ریسک برتر حریم خصوصی](https://owasp.org/www-project-top-10-privacy-risks/)
+- [۱۰ کنترل پیشگیرانه برتر](https://owasp.org/www-project-proactive-controls/)
+- [۱۰ ریسک امنیتی برتر اپلیکیشن‌های وب](https://owasp.org/Top10/)
+
+سایر لیست‌های ده مورد برتر OWASP پروژه‌های «انکوباتور» هستند که در حال انجام می‌باشند، بنابراین این
+لیست با گذشت زمان تغییر خواهد کرد.
+
+---
+
+راهنمای توسعه‌دهندگان OWASP یک تلاش جمعی است؛ اگر چیزی را مشاهده کردید که نیاز به تغییر دارد، لطفاً
+[یک issue ثبت کنید](https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/05-top-ten)
+یا [در GitHub ویرایش کنید](https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/05-top-ten.md).
+
+[samm]: https://owaspsamm.org/about/
\ No newline at end of file
diff --git a/docs/fa/02-foundations/index.md b/docs/fa/02-foundations/index.md
new file mode 100644
index 00000000..467904ab
--- /dev/null
+++ b/docs/fa/02-foundations/index.md
@@ -0,0 +1,26 @@
+![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){ align=right width=180 }
+
+مفاهیم و اصطلاحات پایه‌ای گوناگونی وجود دارند که معمولاً در امنیت نرم‌افزار استفاده می‌شوند.
+اگرچه پیاده‌سازی بسیاری از این مفاهیم پیچیده و مبتنی بر تئوری‌های سنگین است، اما اصول آن‌ها اغلب
+کاملاً سرراست و برای هر مهندس نرم‌افزاری قابل درک است.
+
+درک معقولی از این مفاهیم بنیادی به تیم‌های توسعه اجازه می‌دهد تا امنیت نرم‌افزار را برای اپلیکیشن یا
+سیستمی که در حال توسعه است، درک و پیاده‌سازی کنند.
+
+این راهنمای توسعه‌دهنده تنها می‌تواند یک نمای کلی و مختصر از این مفاهیم ارائه دهد؛ برای دانش عمیق‌تر
+به متون متعدد در زمینه امنیت مانند
+[پیکره دانش امنیت سایبری (The Cyber Security Body Of Knowledge)](https://www.cybok.org/) مراجعه کنید.
+
+اگر قرار است تغییراتی در فرهنگ امنیتی یک سازمان ایجاد شود، اطمینان حاصل کنید که حمایت مدیریت و اهداف
+روشنی برای دستیابی وجود دارد.
+
+بدون این‌ها، تلاش‌ها برای بهبود وضعیت امنیتی احتمالاً با شکست مواجه خواهند شد - برای درک اهمیت همکاری
+تیم‌های مدیریت، امنیت و توسعه، به پروژه
+[فرهنگ امنیت (Security Culture)](https://owasp.org/www-project-security-culture/stable/3-Goal_Setting_and_Security_Team_Collaboration/)
+مراجعه کنید.
+
+---
+
+راهنمای توسعه‌دهندگان OWASP یک تلاش جمعی است؛ اگر چیزی را مشاهده کردید که نیاز به تغییر دارد، لطفاً
+[یک issue ثبت کنید](https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/index)
+یا [در GitHub ویرایش کنید](https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/index.md).
\ No newline at end of file