واجهة برمجة تطبيقات أو مكتبة غير آمنة
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
فئة OWASP: MASVS-CODE: جودة الرمز
نظرة عامة
يؤدي استخدام واجهات برمجة التطبيقات أو المكتبات غير الآمنة إلى تقليل مستوى أمان التطبيق بشكل كبير. سيؤدي حدوث اختراق أمني في أي من هذه التبعيات إلى السماح للمهاجم
باستخدام عدد من المتجهات لتنفيذ مجموعة واسعة من الهجمات، مثل هجمات الوسيط (MitM) وتنفيذ التعليمات البرمجية عن بُعد (RCE).
يظهر خطر استخدام التبعيات غير الآمنة عندما لا يدمج المطوّرون تقييمات الأمان واختبارات الثغرات الأمنية في دورة حياة تطوير البرامج (SDLC)، أو عندما لا يطبّقون في بعض الحالات سياسة تحديث تلقائي لتبعيات التطبيق.
يبدأ استغلال التبعيات عادةً بتحليل الرمز الثنائي للتطبيق (ملف APK) للبحث عن مكتبات معرضة للثغرات. في هذه المرحلة، يتم جمع وتحليل البيانات المفتوحة المصدر (OSINT) للكشف عن الثغرات الأمنية التي تم رصدها سابقًا والتي يُحتمل أن يتم استغلالها. يمكن للمهاجمين بعد ذلك الاستفادة من المعلومات التي تم الإفصاح عنها علنًا بشأن الثغرات الأمنية، مثل الثغرات والمخاطر الأمنية الشائعة (CVE)، لتنفيذ المزيد من الهجمات.
التأثير
يمكن أن يؤدي الاستغلال الناجح للتبعيات غير الآمنة إلى مجموعة واسعة من الهجمات، مثل تنفيذ التعليمات البرمجية عن بُعد (RCE) أو إدخال لغة الاستعلامات البنيوية (SQL) أو النصوص البرمجية للمواقع الإلكترونية المشتركة (XSS).
لذلك، يرتبط التأثير العام بشكل مباشر بنوع الثغرة الأمنية التي يتسبّب فيها برنامج تابع لجهة خارجية ويمكن للمهاجمين استغلالها.
تشمل العواقب المحتملة للاستغلال الناجح للتبعيات المعرَّضة للخطر
اختراقات البيانات أو عدم توفّر الخدمة، ما قد يؤدي إلى تأثير كبير
في السمعة والعائد الاقتصادي.
إجراءات التخفيف
الدفاع في العمق
يُرجى العِلم أنّه يجب تنفيذ إجراءات التخفيف المذكورة أدناه معًا لضمان مستوى أمان أعلى وتقليل مساحة استهداف التطبيق.
يجب دائمًا تقييم النهج الدقيق لكل حالة على حدة.
تقييمات الثغرات الأمنية في التبعيات
استخدِم ميزة التحقّق من التبعيات في بداية دورة حياة التطوير
لرصد الثغرات الأمنية في الرموز البرمجية التابعة لجهات خارجية. تختبر هذه المرحلة ما إذا كان الرمز البرمجي الذي لم يتم إنشاؤه داخليًا آمنًا قبل طرحه في بيئات الإنتاج.
يمكن استكمال عملية التحقّق من خلال تنفيذ أدوات اختبار أمان التطبيقات الثابتة (SAST) واختبار أمان التطبيقات الديناميكية (DAST) ضمن دورة حياة تطوير البرامج لتحسين وضع أمان التطبيق.
تعديل العناصر التابعة باستمرار
يجب الحرص دائمًا على تحديث أي تبعية مضمّنة في الرمز البرمجي بشكل مستمر. لهذا الغرض، يُنصح بتنفيذ تحديثات تلقائية يتم طرحها في الإصدار العلني كلما أصدر أحد المكوّنات التابعة لجهات خارجية حزمة أمان جديدة.
إجراء اختبارات اختراق منتظمة تهدف هذه الأنواع من الاختبارات إلى الكشف عن أي ثغرة أمنية معروفة جيدًا يمكن أن تؤثر في الرموز البرمجية الخاصة و/أو التبعيات الخارجية.
بالإضافة إلى ذلك، تكشف التقييمات الأمنية بشكل متكرّر عن ثغرات أمنية غير معروفة (ثغرات اليوم الصفر).
تُعدّ اختبارات الاختراق مفيدة للمطوّرين لأنّها تقدّم لهم لمحة عن حالة الأمان الحالية للتطبيق وتساعدهم في تحديد أولويات المشاكل الأمنية التي يمكن استغلالها والتي يجب معالجتها.
المراجع
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Insecure API or Library\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-CODE: Code Quality](https://mas.owasp.org/MASVS/10-MASVS-CODE)\n\nOverview\n--------\n\nUsing insecure APIs or libraries significantly reduces an application's security\nposture. A security breach in any of these dependencies would allow an attacker\nto leverage a number of vectors to conduct a broad set of attacks such as man-\nin-the-middle (MitM) and remote code execution (RCE).\n\nThe threat of implementing insecure dependencies arises when developers don't\nintegrate security assessments and vulnerability testing into the Software\nDevelopment Lifecycle (SDLC) or, in some cases, don't implement an automated\nupdate policy for application dependencies.\n\nDependency exploitation usually starts by analyzing application binary (.apk) to\nsearch for vulnerable libraries. At this point, Open Source Intelligence (OSINT)\nis performed to unearth previously discovered potentially exploitable\nvulnerabilities. Attackers can then leverage publicly disclosed vulnerability\ninformation such as common vulnerabilities and exposures (CVEs) to perform\nfurther attacks.\n\nImpact\n------\n\nThe successful exploitation of insecure dependencies can lead to a broad set of\nattacks such as remote code execution (RCE), SQL injections (SQLi), or cross-\nsite scripting (XSS).\nTherefore, the overall impact is directly related to the type of vulnerability\nthat third-party software introduces and that attackers can exploit.\nPossible consequences of a successful exploitation of vulnerable dependencies\nare data breaches or service unavailability, which may lead to a significant\nimpact on reputation and economic turnover.\n\nMitigations\n-----------\n\n### Defense in depth\n\nNote that the mitigations listed below have to be implemented in combination to\nensure a stronger security posture, and reduce the application's attack surface.\nThe exact approach should always be evaluated on a case-by-case basis.\n\n### Dependency vulnerability assessments\n\nImplement dependency verification at the beginning of the development lifecycle\nto detect vulnerabilities within third-party code. This phase tests whether the\ncode that is not built in-house is secure before being rolled out in production\nenvironments.\nVerification could be complemented by implementing static application security\ntesting (SAST) and dynamic application security testing (DAST) tools within the\nsoftware development lifecycle to improve the security posture of the\napplication.\n\n### Continuously update dependencies\n\nAlways be careful to continuously update any dependency embedded within the\ncode. For this purpose, it is recommended to implement automatic updates that\nare pushed to production whenever a third-party component releases a new\nsecurity patch.\n\n### Perform application penetration testing\n\nConduct regular penetration tests. These kinds of tests aim to uncover any well-\nknown vulnerability that could affect proprietary code and, or third-party\ndependencies.\nAdditionally, security assessments frequently uncover unknown vulnerabilities\n(0-days).\nPenetration tests are helpful for developers, as they provide them with a\nsnapshot of the application's current security posture and help them prioritize\nexploitable security issues that have to be addressed.\n\nResources\n---------\n\n- [How to recognise and manage insecure dependencies](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)\n\n- [GitHub security features](https://docs.github.com/en/code-security/getting-started/github-security-features)\n\n- [How to secure dependencies](https://www.hacksplaining.com/prevention/toxic-dependencies)\n\n- [CWE-1395: Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html)\n\n- [SDK implementation best-practices for Android.](/guide/practices/sdk-best-practices)"]]
