API سیکیورٹی کے بہترین طرز عمل: توثیق، اجازت اور شرح کی حد بندی

APIs جدید کاروباری پلیٹ فارمز کے مربوط ٹشو ہیں۔ آپ کا ERP APIs کے ذریعے آپ کے ای کامرس اسٹور کے ساتھ بات چیت کرتا ہے۔ آپ کا ادائیگی کا گیٹ وے APIs کے ذریعے لین دین پر کارروائی کرتا ہے۔ آپ کی موبائل ایپ APIs کے ذریعے ڈیٹا حاصل کرتی ہے۔ اور حملہ آور یہ جانتے ہیں: گارٹنر نے پیش گوئی کی ہے کہ 2026 تک، APIs روایتی ویب انٹرفیس کو پیچھے چھوڑتے ہوئے انٹرپرائز ویب ایپلیکیشنز کے لیے سب سے زیادہ حملہ آور ہوں گے۔

OWASP API سیکورٹی ٹاپ 10 سے پتہ چلتا ہے کہ سب سے زیادہ عام API کمزوریاں غیر ملکی صفر دنوں کی نہیں ہیں --- وہ بنیادی توثیق کی ناکامیاں، ٹوٹی ہوئی اجازت، اور ضرورت سے زیادہ ڈیٹا کی نمائش ہیں۔ یہ روکے جانے والے نقائص ہیں جو جدید ترین حملوں کے بجائے ناکافی حفاظتی فن تعمیر سے پیدا ہوتے ہیں۔

اہم ٹیک ویز

• PKCE کے ساتھ OAuth2 API کی توثیق کا موجودہ معیار ہے۔ پروڈکشن سسٹمز کے لیے اکیلے API کیز ناکافی ہیں۔
• ٹوٹے ہوئے آبجیکٹ لیول کی اجازت (BOLA) نمبر ایک API کمزوری ہے --- ہر اختتامی نقطہ کو وسائل کی ملکیت کی تصدیق کرنی چاہیے
• شرح کو محدود کرنا ایک سیکیورٹی کنٹرول ہے، نہ کہ صرف کارکردگی کی اصلاح --- یہ اسناد کی بھرائی، گنتی، اور DoS کو روکتا ہے۔
• API باؤنڈری پر ان پٹ کی توثیق انجیکشن، اوور فلو، اور کاروباری منطق کے حملوں کو آپ کے ڈیٹا بیس تک پہنچنے سے پہلے روکتی ہے۔

---

توثیق: شناخت ثابت کرنا

توثیق اس سوال کا جواب دیتی ہے کہ "یہ درخواست کون کر رہا ہے؟" APIs کے لیے، جواب کو خفیہ طور پر قابل تصدیق، ری پلے حملوں کے لیے مزاحم، اور تقسیم شدہ نظاموں میں توسیع پذیر ہونا چاہیے۔

توثیق کے طریقہ کا موازنہ

OAuth2 اور OIDC بہترین طرز عمل

اوپن آئی ڈی کنیکٹ (OIDC) کے ساتھ OAuth2 جدید ایپلی کیشنز میں API کی تصدیق کا معیار ہے۔ کلیدی نفاذ کے طریقے:

PKCE کے ساتھ اجازتی کوڈ کا بہاؤ استعمال کریں تمام کلائنٹ اقسام بشمول سنگل پیج ایپلیکیشنز اور موبائل ایپس کے لیے۔ براؤزر کی تاریخ اور حوالہ دینے والے ہیڈر میں ٹوکن کی نمائش کی وجہ سے مضمر بہاؤ فرسودہ ہے۔

قلیل المدت رسائی کے ٹوکن۔ رسائی کے ٹوکنز کی میعاد 15-60 منٹ میں ختم ہو جانی چاہیے۔ دوبارہ توثیق کے بغیر نئے رسائی ٹوکن حاصل کرنے کے لیے ریفریش ٹوکنز (محفوظ طریقے سے ذخیرہ کیے گئے، استعمال پر گھمائے گئے) کا استعمال کریں۔

ٹوکن اسٹوریج۔ کبھی بھی لوکل اسٹوریج یا سیشن اسٹوریج میں ٹوکن اسٹور نہ کریں (XSS کا خطرہ)۔ HttpOnly کوکیز کو محفوظ اور SameSite کی خصوصیات کے ساتھ استعمال کریں۔ ایس پی اے کے لیے جو ٹوکنز کا براہ راست استعمال کریں، انہیں صرف میموری میں رکھیں اور صفحہ ریفریش پر سیشن کے نقصان کی تجارت کو قبول کریں۔

ٹوکنز کی اچھی طرح سے تصدیق کریں۔ ہر API درخواست کو ٹوکن کے دستخط، میعاد ختم ہونے، جاری کنندہ، سامعین اور دائرہ کار کی تصدیق کرنی چاہیے۔ JWT کو محض ڈی کوڈ نہ کریں اور اس کے مندرجات پر بھروسہ کریں۔

ٹوکن بائنڈنگ۔ جہاں ممکن ہو، اس کلائنٹ کو ٹوکن بائنڈ کریں جس نے ٹوکن چوری اور ری پلے کو روکنے کے لیے ڈی پی او پی (ڈیمانسٹریٹنگ پروف آف پزیشن) ہیڈر استعمال کرنے کی درخواست کی تھی۔

JWT سیکیورٹی کے تحفظات

JWTs APIs کے لیے سب سے عام ٹوکن فارمیٹ ہیں، لیکن ان میں مخصوص خطرات ہوتے ہیں:

• کبھی بھی none الگورتھم استعمال نہ کریں۔ ہمیشہ متوقع الگورتھم کی وائٹ لسٹ کے خلاف alg ہیڈر کی توثیق کریں۔
• عوام کا سامنا کرنے والے APIs کے لیے ہم آہنگی (HS256) پر غیر متناسب الگورتھم (RS256, ES256) کو ترجیح دیں۔ غیر متناسب کلیدیں دستخطی کلید کا اشتراک کیے بغیر ٹوکن کی تصدیق کی اجازت دیتی ہیں۔
• معیاری دعوے شامل کریں: iss (جاری کنندہ)، aud (سامعین)، exp (میعاد ختم ہونے)، iat (جاری ہونے پر)، sub (موضوع)، jti (منسوخی کے لیے منفرد ID)۔
• پے لوڈز کو چھوٹا رکھیں۔ JWTs ڈیٹا بیس نہیں ہیں۔ اجازت کے فیصلوں کے لیے درکار صرف دعوے شامل کریں۔ ضرورت پڑنے پر صارف کی معلومات کے اختتامی مقامات سے اضافی ڈیٹا حاصل کریں۔
• ٹوکن کی تنسیخ کو لاگو کریں۔ جب اکاؤنٹس سے سمجھوتہ کیا جاتا ہے تو فوری طور پر منسوخی کے لیے ٹوکن بلاک لسٹ (ریڈیز یا اس سے ملتی جلتی) کے ساتھ مختصر مدت ختم ہونے کا استعمال کریں۔

---

اجازت: رسائی کنٹرول کو نافذ کرنا

توثیق آپ کو بتاتی ہے کہ درخواست کون کر رہا ہے۔ اجازت آپ کو بتاتی ہے کہ انہیں کیا کرنے کی اجازت ہے۔ OWASP API ٹاپ 10 میں بروکن آبجیکٹ لیول آتھرائزیشن (BOLA) کو نمبر ایک API کے خطرے کے طور پر درج کیا گیا ہے کیونکہ یہ سب سے زیادہ عام اور سب سے زیادہ اثر انگیز ہے۔

RBAC بمقابلہ ABAC

رول بیسڈ ایکسیس کنٹرول (RBAC) کرداروں کے لیے اجازتیں تفویض کرتا ہے، اور صارفین کو کردار تفویض کیے جاتے ہیں۔ اس پر عمل درآمد اور استدلال کرنا آسان ہے۔

انتساب پر مبنی رسائی کنٹرول (ABAC) صارف کی صفات، وسائل، عمل اور ماحول کے خلاف پالیسیوں کا جائزہ لیتا ہے۔ یہ زیادہ پیچیدہ قوانین کی حمایت کرتا ہے لیکن اس کا آڈٹ کرنا مشکل ہے۔

زیادہ تر کاروباری پلیٹ فارمز بشمول ERP اور ای کامرس سسٹمز کے لیے، RBAC وسائل کی ملکیت کی جانچ کے ساتھ مل کر کافی ہے۔ ABAC پر غور کریں جب آپ کی اجازت کے قواعد سیاق و سباق کے عوامل پر منحصر ہوں جیسے وقت، مقام، ڈیٹا کی درجہ بندی، یا متحرک تنظیمی درجہ بندی۔

بولا کی روک تھام

ٹوٹے ہوئے آبجیکٹ لیول کی اجازت اس وقت ہوتی ہے جب ایک API صارفین کو وسائل کے شناخت کنندگان میں ہیرا پھیری کرکے دوسرے صارفین کے وسائل تک رسائی یا ان میں ترمیم کرنے کی اجازت دیتا ہے۔ مثال کے طور پر، /api/orders/12345 کو /api/orders/12346 میں تبدیل کرنے سے دوسرے صارف کا آرڈر ظاہر نہیں ہونا چاہئے۔

روک تھام کے اصول:

1. ہر اختتامی نقطہ کو وسائل کی ملکیت کی تصدیق کرنی چاہیے۔ کبھی بھی مکمل طور پر تصدیق پر انحصار نہ کریں۔ صارف کی شناخت کی توثیق کرنے کے بعد، تصدیق کریں کہ ان کے پاس درخواست کردہ مخصوص وسائل تک رسائی ہے۔
2. بالواسطہ حوالہ جات استعمال کریں۔ ترتیب وار ڈیٹابیس IDs کو ظاہر کرنے کے بجائے، UUIDs یا صارف کے دائرہ کار والے حوالہ نمبرز کا استعمال کریں۔
3. ڈیٹا کی سطح پر لاگو کریں۔ ہر ڈیٹا بیس کے استفسار پر ملکیت کے فلٹرز (جیسے، WHERE organization_id = ?) شامل کریں، نہ صرف کنٹرولر کی سطح پر۔ یہ کثیر کرایہ داری کا نمونہ ہے جو پورے ECOSIRE کے پلیٹ فارم فن تعمیر میں استعمال ہوتا ہے۔
4. خودکار جانچ۔ اپنی CI/CD پائپ لائن میں اجازت کے بائی پاس ٹیسٹ شامل کریں۔ ہر ایک اختتامی نقطہ کے لیے، جانچ کریں کہ صارف A صارف B کے وسائل تک رسائی حاصل نہیں کر سکتا۔

---

شرح کی حد بندی اور تھروٹلنگ

شرح محدود کرنا ایک حفاظتی کنٹرول ہے جو غلط استعمال کو روکتا ہے، نہ صرف کارکردگی کی اصلاح جو اوورلوڈ کو روکتا ہے۔ شرح کو محدود کیے بغیر، حملہ آور فی سیکنڈ ہزاروں کوششوں پر اسناد بھر سکتے ہیں، درست اکاؤنٹس کی گنتی کر سکتے ہیں، آپ کے پورے پروڈکٹ کیٹلاگ کو ختم کر سکتے ہیں، یا اپ اسٹریم فراہم کنندگان کے ساتھ آپ کے API کوٹہ کو ختم کر سکتے ہیں۔

شرح کو محدود کرنے کی حکمت عملی

شرح اختتامی قسم کے لحاظ سے محدود

مختلف اختتامی مقامات کو مختلف خطرات کے پروفائلز کا سامنا کرنا پڑتا ہے اور مختلف حدود کی ضرورت ہوتی ہے:

• توثیق کے اختتامی نقطہ (لاگ ان، ٹوکن ایکسچینج): فی منٹ 5-10 درخواستیں فی IP۔ کم حدیں اسناد بھرنے اور بریٹ فورس کو روکتی ہیں۔
• پاس ورڈ ری سیٹ/اکاؤنٹ ریکوری: فی اکاؤنٹ فی گھنٹہ 3-5 درخواستیں۔ اکاؤنٹ کی گنتی اور غلط استعمال کو روکتا ہے۔
• ڈیٹا ریڈ پوائنٹس: فی صارف فی منٹ 100-1000 درخواستیں۔ عام استعمال کی اجازت دیتے ہوئے سکریپنگ کو روکتا ہے۔
• ڈیٹا تحریری اختتامی نقطہ: فی صارف 30-60 درخواستیں فی منٹ۔ خودکار غلط استعمال اور اسپام کو روکتا ہے۔
• عوامی تلاش کے اختتامی نقطہ: فی منٹ فی IP 20-60 درخواستیں۔ مسابقتی سکریپنگ کو روکتا ہے۔
• ویب ہک ریسیورز: ریٹ محدود کرنے کے بجائے دستخطوں کی توثیق کریں، لیکن متوقع حجم سے زیادہ درخواستوں کو چھوڑ دیں۔

شرح کی حدود کو نافذ کرنا

مناسب HTTP اسٹیٹس کوڈز اور ہیڈر واپس کریں تاکہ کلائنٹ خود کو منظم کر سکیں:

• 429 بہت زیادہ درخواستیں جب حد سے تجاوز کیا جائے۔
• دوبارہ کوشش کے بعد ہیڈر سیکنڈوں کی تعداد کے ساتھ جب تک کہ حد دوبارہ سیٹ نہ ہوجائے
• X-RateLimit-Limit ہیڈر کل اجازت شدہ درخواستوں کو دکھا رہا ہے۔
• X-Rate Limit-Remaining ہیڈر ونڈو میں رہ گئی درخواستوں کو دکھا رہا ہے۔
• ونڈو کے دوبارہ سیٹ ہونے پر UTC ٹائم اسٹیمپ کے ساتھ X-RateLimit-Reset ہیڈر

ایک سنٹرلائزڈ ریٹ محدود کرنے والی سروس (Redis-backed) کا استعمال کریں، بجائے اس کے کہ حملہ آوروں کو تمام مثالوں میں درخواستیں تقسیم کرنے سے روکا جائے تاکہ وہ حدود کو نظرانداز کریں۔

---

ان پٹ کی توثیق

API باؤنڈری پر ان پٹ کی توثیق انجیکشن حملوں، بفر اوور فلو، اور کاروباری منطق کے استحصال کے خلاف آپ کے دفاع کی پہلی لائن ہے۔ آپ کے API میں داخل ہونے والے ڈیٹا کے ہر ٹکڑے کی قسم، شکل، لمبائی، رینج، اور کاروباری قواعد کے لیے توثیق ہونی چاہیے۔

OWASP API سیکیورٹی ٹاپ 10

OWASP API سیکیورٹی ٹاپ 10 (2023 ایڈیشن) ان اہم خطرات کی نشاندہی کرتا ہے جن کو ہر API کو حل کرنا چاہیے:

توثیق کے بہترین طریقے

اسکیما کی توثیق۔ درخواست کی اسکیموں کی وضاحت کریں (JSON اسکیما، Zod، یا OpenAPI spec کا استعمال کرتے ہوئے) اور کسی بھی ایسی درخواست کو مسترد کریں جو موافق نہیں ہے۔ یہ خراب ڈیٹا کو کاروباری منطق تک پہنچنے سے پہلے پکڑ لیتا ہے۔

پیرامیٹرائزڈ سوالات۔ کبھی بھی صارف کے ان پٹ کو SQL، NoSQL، یا LDAP سوالات میں مت جوڑیں۔ پیرامیٹرائزڈ استفسارات یا ORM طریقے استعمال کریں جو خود بخود فرار ہونے کو ہینڈل کرتے ہیں۔ یہ تمام کاروباری پلیٹ فارمز کے لیے ایک اہم حفاظتی اصول ہے۔

مواد کی قسم کا نفاذ۔ صرف متوقع مواد کی قسم ہیڈر قبول کریں۔ ایک API جو JSON کی توقع رکھتا ہے اسے XML، فارم ڈیٹا، اور دیگر مواد کی اقسام کو پارسر پر مبنی حملوں کو روکنے کے لیے مسترد کرنا چاہیے۔

ریسپانس فلٹرنگ۔ کبھی بھی کلائنٹ کو مکمل ڈیٹا بیس ریکارڈ واپس نہ کریں۔ DTOs (ڈیٹا ٹرانسفر آبجیکٹ) کو واضح طور پر بیان کرنے کے لیے استعمال کریں کہ ہر جواب میں کون سے فیلڈز شامل ہیں۔ اندرونی فیلڈز جیسے پاس ورڈ ہیشز، اندرونی IDs، اور آڈٹ میٹا ڈیٹا کبھی بھی API کے جوابات میں ظاہر نہیں ہونا چاہیے۔

خرابی کو سنبھالنا۔ کلائنٹس کو عمومی غلطی کے پیغامات واپس کریں۔ اسٹیک ٹریس، ڈیٹا بیس کی خامیاں، یا اندرونی نظام کی تفصیلات کو کبھی بھی ظاہر نہ کریں۔ ڈیبگنگ کے لیے سرور کی طرف سے تفصیلی غلطیوں کو لاگ کریں۔

---

API سیکیورٹی آرکیٹیکچر پیٹرنز

API گیٹ وے پیٹرن

ایک API گیٹ وے تمام بیک اینڈ سروسز کے سامنے بیٹھتا ہے اور کراس کٹنگ سیکیورٹی خدشات کو مرکزی بناتا ہے:

• توثیق --- درخواستوں کے بیک اینڈ سروسز تک پہنچنے سے پہلے ٹوکن کی توثیق کرتا ہے۔
• ریٹ محدود کرنا --- گیٹ وے کی سطح پر حدود کو نافذ کرتا ہے۔
• درخواست/جواب کی تبدیلی --- حساس ہیڈر کو سٹرپس کرتا ہے، سیکورٹی ہیڈر کا اضافہ کرتا ہے
• لاگنگ اور مانیٹرنگ --- سیکیورٹی کے تجزیہ کے لیے تمام API ٹریفک کو کیپچر کرتا ہے۔
• WAF انضمام --- بلاکس حملے کے معلوم نمونے (SQL انجیکشن، XSS پے لوڈز)

مقبول API گیٹ ویز میں کانگ، AWS API گیٹ وے، Azure API مینجمنٹ، اور Traefik شامل ہیں۔

سروس سے سروس کی توثیق

مائیکرو سروسز کے درمیان اندرونی APIs کو بھی تصدیق کی ضرورت ہوتی ہے۔ اختیارات میں شامل ہیں:

• Mutual TLS (mTLS) --- کلائنٹ اور سرور دونوں سرٹیفکیٹ پیش کرتے ہیں۔ مضبوط لیکن عملی طور پر پیچیدہ۔
• سروس ٹوکن--- سروسز پہلے سے شیئر کردہ ٹوکنز کے ساتھ تصدیق کرتی ہیں۔ آسان لیکن محفوظ تقسیم درکار ہے۔
• سروس میش --- Istio یا Linkerd mTLS کو خود بخود Kubernetes میں خدمات کے درمیان ہینڈل کرتا ہے۔
• OAuth2 کلائنٹ کی اسناد --- رسائی ٹوکن حاصل کرنے کے لیے خدمات کلائنٹ آئی ڈی اور خفیہ کا استعمال کرتے ہوئے تصدیق کرتی ہیں۔

صفر ٹرسٹ آرکیٹیکچر کے لیے، خلاف ورزی کے بعد پس منظر کی نقل و حرکت کو روکنے کے لیے خدمت سے خدمت کی توثیق ضروری ہے۔

---

نگرانی اور واقعات کا پتہ لگانا

API سیکیورٹی مانیٹرنگ کو تکنیکی سگنلز (تصدیق کی ناکام کوششیں، غیر معمولی درخواست کے نمونے) اور کاروباری سگنلز (غیر معمولی لین دین کی مقدار، بلک ڈیٹا تک رسائی) دونوں کو حاصل کرنا چاہیے۔

اہم API سیکیورٹی سگنل

• توثیق کی ناکامیاں --- ایک ہی IP سے ناکام لاگ ان میں اضافہ یا ایک اکاؤنٹ کو نشانہ بنانا
• ** اجازت دینے میں ناکامیاں** --- 403 جوابات جو یہ بتاتے ہیں کہ صارفین غیر مجاز وسائل تک رسائی کی کوشش کر رہے ہیں
• شرح کی حد کی خلاف ورزیاں --- ایک ہی ذریعہ سے مسلسل 429 جوابات
• غیرمعمولی ڈیٹا والیوم --- بلک ریڈ آپریشنز جو ڈیٹا کو نکالنے کا مشورہ دیتے ہیں۔
• پیرامیٹر سے چھیڑ چھاڑ --- ترتیب وار ID کی گنتی، منفی اقدار، باؤنڈری ٹیسٹنگ
• جغرافیائی بے ضابطگیاں --- غیر متوقع علاقوں یا ناممکن سفری نمونوں سے API کالز

ڈیش بورڈز بنائیں جو ان سگنلز کو حقیقی وقت میں ظاہر کریں۔ دیگر سیکیورٹی ایونٹس کے ساتھ ارتباط کے لیے اپنے SIEM کے ساتھ مربوط ہوں۔ اعلیٰ اعتماد کے خطرات کے لیے خودکار جوابات کی وضاحت کریں: ناکام تصدیقی حد سے تجاوز کرنے والے IPs کو بلاک کریں، ناممکن سفر کی نمائش کرنے والے اکاؤنٹس کو عارضی طور پر غیر فعال کریں، اور بلک ڈیٹا تک رسائی کے نمونوں پر الرٹ کریں۔

---

اکثر پوچھے گئے سوالات

کیا مجھے API کیز یا OAuth2 ٹوکن استعمال کرنے چاہئیں؟

کسی بھی API کے لیے OAuth2 ٹوکنز استعمال کریں جو صارف کا سامنا کرنے والی ایپلیکیشنز یا فریق ثالث کے انضمام کو پیش کرتا ہے۔ API کیز صرف سرور سے سرور مواصلات کے لیے قابل قبول ہیں جہاں دونوں اختتامی نقطہ آپ کے کنٹرول میں ہیں، اور اس کے باوجود، HMAC کے دستخط شدہ درخواستیں مضبوط سیکیورٹی فراہم کرتی ہیں۔ عوامی طور پر قابل رسائی اختتامی پوائنٹس کے لیے کبھی بھی API کیز کو واحد توثیق کے طور پر استعمال نہ کریں۔

میں API ورژننگ کو محفوظ طریقے سے کیسے ہینڈل کروں؟

وضاحت اور دریافت کے لیے URL پر مبنی ورژننگ (جیسے، /api/v2/orders) استعمال کریں۔ کسی ورژن کو فرسودہ کرتے وقت، غروب آفتاب کی تاریخ مقرر کریں، اسے صارفین تک پہنچائیں، اور استعمال کی نگرانی کریں۔ فرسودہ ورژن پر سیکیورٹی پیچ لگانا جاری رکھیں جب تک کہ وہ مکمل طور پر ریٹائر نہ ہوجائیں۔ بغیر پیچ والے پرانے API ورژنوں کو چلتے ہوئے کبھی نہ چھوڑیں --- وہ آسان ہدف بن جاتے ہیں۔

کاروباری API کے لیے مجھے شرح کی کیا حدیں مقرر کرنی چاہیے؟

قدامت پسند شروع کریں اور جائز استعمال کے اعداد و شمار کی بنیاد پر اضافہ کریں۔ توثیق کے اختتامی پوائنٹس کے لیے، فی منٹ فی IP 5-10 درخواستیں معیاری ہیں۔ ڈیٹا اینڈ پوائنٹس کے لیے، فی توثیق شدہ صارف فی منٹ 100-500 درخواستیں زیادہ تر کاروباری استعمال کے معاملات کا احاطہ کرتی ہیں۔ حدوں کی نشاندہی کرنے کے لیے 429 جوابات کی نگرانی کریں جو بہت زیادہ محدود ہیں، اور غلط استعمال کے نمونوں کی نگرانی کریں تاکہ ان حدوں کی نشاندہی کی جا سکے جو بہت فراخ ہیں۔

میں تیسرے فریق کی خدمات سے ویب ہکس کیسے محفوظ کروں؟

مشترکہ راز کے ساتھ HMAC-SHA256 کا استعمال کرتے ہوئے ویب ہک دستخطوں کی تصدیق کریں۔ ری پلے حملوں کو روکنے کے لیے ٹائم اسٹیمپ کی توثیق کریں (5 منٹ سے زیادہ پرانے واقعات کو مسترد کریں)۔ سروس کے ٹائم آؤٹ پر مبنی انکار کو روکنے کے لیے ویب ہکس پر غیر مطابقت پذیری سے کارروائی کریں۔ آڈٹ کے مقاصد کے لیے تمام ویب ہک ایونٹس کو لاگ کریں۔ پروسیسنگ سے پہلے پے لوڈ اسکیما کی توثیق کریں۔

---

آگے کیا ہے۔

API سیکیورٹی وہ خصوصیت نہیں ہے جسے آپ ترقی کے اختتام پر شامل کرتے ہیں --- یہ ایک ڈیزائن اصول ہے جو پہلے اختتامی نقطہ سے موجود ہونا ضروری ہے۔ مضبوط تصدیق (OAuth2/OIDC) کے ساتھ شروع کریں، وسائل تک رسائی کے ہر مقام پر اجازت کو نافذ کریں، تمام اختتامی قسموں میں شرح کو محدود کرنے کو لاگو کریں، اور ہر ان پٹ کی توثیق کریں جو آپ کی API کی حد سے تجاوز کرتا ہے۔

ECOSIRE ہر API انضمام میں سیکیورٹی بناتا ہے۔ ہمارا OpenClaw AI پلیٹ فارم HMAC کے دستخط شدہ درخواستوں، شرح کو محدود کرنے، اور SSRF تحفظ کو بطور ڈیفالٹ نافذ کرتا ہے، جبکہ ہمارا Odoo ERP انضمام OAuth2/OIDC کو رول پر مبنی رسائی کنٹرول کے ساتھ استعمال کرتا ہے۔ اپنے کاروباری پلیٹ فارم APIs کو محفوظ بنانے کے لیے ہماری ٹیم سے رابطہ کریں۔

---

شائع کردہ بذریعہ ECOSIRE --- Odoo ERP، Shopify eCommerce، اور OpenClaw AI میں AI سے چلنے والے حل کے ساتھ کاروبار کو پیمانے میں مدد کرنا۔