واجهات API للأطفال: كيف نمنع تطبيقات الطرف الثالث من تجاوز حماية الحساب؟

قد يكون التطبيق الرئيسي مصممًا بخصوصية عالية للأطفال، ثم تفتح الشركة API تسمح لتطبيق خارجي بقراءة الملف أو الأصدقاء أو الرسائل أو الموقع أو رفع محتوى نيابة عن المستخدم. عندها يمكن أن تتجاوز طبقة المطورين الحماية التي بُنيت في الواجهة الأصلية من دون أي اختراق تقني. لذلك لا يكفي القول إن المستخدم وافق على OAuth. المنصة التي تعرف أو تتوقع وجود قاصرين تحتاج أن تحدد ما الذي يمكن لتطبيقات الطرف الثالث الوصول إليه أصلًا، وكيف تُراجع هوية المطور وغرضه، وما scopes التي يُسمح بها لحساب طفل، وكيف تُسحب الصلاحيات فورًا عند إساءة الاستخدام أو تغير العمر أو حذف الحساب.

API هو سطح منتج وليس Backend محايدًا

كل endpoint يخلق قدرة جديدة خارج UI الأصلي. إذا كان child profile خاصًا لكن API يعيد email أو birth date أو friend list لتطبيق مصرح، فالخصوصية الفعلية تعتمد على API أيضًا. اجعل threat model يشمل REST وGraphQL وwebhooks وSDKs وdeveloper console وexport jobs. لا تعتبر أنها أدوات للمطورين فقط؛ هي جزء من تجربة المستخدم وحقوقه.

ما لا تستطيع فعله في الواجهة لا تسمح به سرًا عبر API

إذا لا يستطيع المستخدم تنزيل قائمة أصدقاء قاصر كاملة من UI، فكر جيدًا قبل أن تمنح تطبيقًا خارجيًا bulk endpoint يفعل ذلك. إذا تمنع الرسائل من الغرباء، لا تسمح app token بإرسال DM مباشرة. parity بين الواجهة والAPI قاعدة فحص مهمة؛ الاستثناء يحتاج غرضًا مبررًا وضوابط أقوى.

OAuth Scope يجب أن يصف الغرض لا اسم قاعدة البيانات

scope مثل read_all_data غير مناسب. استخدم صلاحيات دقيقة مثل read_basic_profile أو upload_user_selected_file، وافصل القراءة عن الكتابة. لا تطلب contacts وmessages لأن المطور قد يحتاج username فقط. شاشة الموافقة تشرح بلغة بشرية ما يستطيع التطبيق فعله، وخصوصًا للقاصر. لا تعرض قائمة تقنية من identifiers فقط.

Least Privilege يبدأ من Default Scopes

التطبيق الجديد لا يحصل على كل scopes المتاحة ثم يزيل ما لا يريد. ابدأ بلا بيانات حساسة، واطلب مراجعة إضافية لcontacts وlocation وmessages والpayments والage signals. scopes عالية الخطورة قد تكون غير متاحة أصلًا للقاصرين أو تحتاج نوع تطبيق موثقًا وعقدًا خاصًا. لا تجعل growth incentive يدفع المطور لطلب المزيد لمجرد أن approval أسهل مرة واحدة.

Developer Verification ليس Checkbox واحدًا

تحقق من هوية المطور أو الشركة، domain، contact أمني، privacy policy، use case وownership للتطبيق. لمزيد من scopes، اطلب وصف data flow وretention وsubprocessors. لا تعتبر وجود بطاقة دفع أو بريد عمل دليلًا كافيًا. developer account المخترق يحتاج recovery وMFA وaudit logs مثل حساب المستخدم.

Child-directed App يحتاج Classification مستقلًا

قد يكون التطبيق الخارجي موجّهًا للأطفال، مختلط الجمهور، أو للبالغين لكنه يستطيع الاتصال بحساب قاصر. لا تجعل developer يختار category منخفضة المخاطر دون تحقق. استخدم declaration مع مراجعة signals وstore listing وuse case. إذا كان التطبيق للبالغين فقط، API يجب أن يمنع child account data بدل الاعتماد على developer ليكتشف العمر بنفسه.

Age Signal أقل من تاريخ الميلاد الكامل غالبًا

إذا يحتاج تطبيق معرفة هل feature مسموحة للقاصر، قد يكفي age band أو eligibility boolean. لا ترسل birth date الكامل أو وثيقة age assurance. صمم privacy-preserving claims مثل is_minor أو permitted_feature_set مع صلاحية زمنية ومصدر ثقة. تجنب أن يصبح age signal مفتاحًا لبناء profiling عبر التطبيقات.

لا تسمح للتطبيق بطلب عمر جديد لتجاوز المنصة

إذا platform تعرف أن الحساب طفل، لا تسمح third-party app بتغيير age class بمجرد form داخلي. يمكن للتطبيق جمع عمر لغرض مستقل إذا كان مشروعًا، لكنه لا يغيّر حماية المنصة إلا عبر workflow رسمي. أي تعارض يحتاج policy: الأكثر حماية حتى يثبت التصحيح.

Refresh Tokens عالية الأثر

access token قصير يمكن أن ينتهي، لكن refresh token قد يبقي التطبيق متصلًا أشهرًا. استخدم rotation، audience restriction، sender-constrained tokens حيث يناسب، وrevocation. للقاصرين، راجع connections القديمة دوريًا. لا تجعل تطبيقًا لم يُستخدم سنة يستمر في تنزيل البيانات يوميًا لأن token صالح.

OAuth Security BCP يرفض أنماطًا قديمة عالية الخطر

RFC 9700 يحدّث أفضل الممارسات الأمنية لـOAuth 2.0، بما في ذلك تجنب flows ضعيفة وحماية authorization codes وrefresh tokens ومقاومة redirect URI attacks. هذه إرشادات أمن عامة؛ عند الأطفال أضف فوقها قيود scopes والعمر والبيانات. لا تجعل امتثال OAuth نفسه دليلًا على child safety.

Redirect URI جزء من سلسلة الثقة

سجّل exact redirect URIs ولا تستخدم wildcards واسعة لتطبيقات حساسة. إذا يستطيع مهاجم السيطرة على subdomain أو custom scheme، قد يسرق authorization code. للتطبيقات المحمولة استخدم ممارسات platform المعروفة مثل claimed HTTPS أو PKCE. لا تعرض للطفل صفحة موافقة ثم ترسله إلى domain لا يطابق المطور.

PKCE وState لا يعوضان Scopes واسعة

ضوابط protocol تمنع أنواعًا من الهجمات، لكنها لا تمنع تطبيقًا شرعيًا من إساءة بيانات حصل عليها قانونيًا تقنيًا. لذلك راقب use after grant، retention، API patterns وdeveloper compliance. الأمن والخصوصية والchild-safety طبقات منفصلة تتكامل.

Webhooks قد تدفع البيانات بعد سحب الحاجة

إذا اشترك التطبيق في events مثل message_created أو location_update، لا يكفي إيقاف API read. عند revoke أو تغير age، ألغِ subscriptions فورًا. وقّع webhooks، امنع replay، واستخدم payload minimal. لا ترسل content كاملًا إذا event id يكفي ليقرأ التطبيق ما هو مخول له.

Bulk Export أعلى خطرًا من Query صغير

endpoint يصدر ألف ملف أو social graph كامل يحتاج review مختلفًا عن fetch profile واحد. ضع quotas، asynchronous approval، purpose limits وaudit. للقاصرين، قد تمنع bulk export تمامًا للتطبيقات العامة. لا تسمح للمطور ببناء mirror database لكل طفل بحجة تحسين الأداء.

Social Graph API قد يكشف الطفل عبر أصدقائه

حتى إذا أخفيت اسم الطفل، friend list وschool group وmutual connections قد تعيد التعرف عليه. لا ترسل graph كاملًا. استخدم count أو mutual yes/no إذا كان ذلك يكفي. امنع scraping بالمعدلات والlimits، وراقب apps التي تمشي graph breadth-first.

Contacts Upload عبر API يحتاج ضوابط خاصة

تطبيق خارجي قد يرفع address book ليطابق مستخدمين. لا تمنحه raw directory لكل platform users. نفذ matching server-side وأعد minimal result. لا تكشف أن رقمًا يعود لطفل إذا privacy settings تمنع discovery. احذف uploads غير اللازمة بعد المطابقة.

Messages API لا يفتح قناة خلفية

إذا تسمح API بإرسال رسائل، طبّق نفس age/contact/block/rate/moderation rules التي تطبقها الواجهة. لا يستطيع bot أو third-party app مراسلة طفل لأنه application actor. كل message يحمل provenance يسمح للمستخدم معرفة أنه أُرسل عبر تطبيق خارجي وحظره أو سحب الوصول.

Media Upload يحتاج فحصًا مثل التطبيق الأصلي

لا تجعل API طريقًا لتجاوز image/video moderation أو limits. طبّق نفس أو أقوى pipelines، مع metadata عن developer app. إذا المادة لقاصر، لا تسمح بتعطيل safety processing عبر parameter. استخدم test sandbox لمواد آمنة ومصطنعة، لا real abuse content.

Location API يجب أن تكون استثناءً نادرًا

precise child location عالية الحساسية. معظم تطبيقات الطرف الثالث لا تحتاجها. إذا يوجد use case مثل safety device، استخدم review وعقدًا وshort-lived access ومؤشرًا للمستخدم، ولا تسمح bulk history. guardian approval لا يكفي إذا app غير موثوق أو الغرض واسع.

Payments API لا يربط الإنفاق بالوصول الاجتماعي

إذا developer app يستطيع شراء gift أو subscription، لا تمنحه حق DM أو friend بسبب payment. طبّق age/payment limits، refund وfraud controls. لا تعيد card data أو billing address إلا للجهة التي تحتاجها قانونيًا. استخدم tokenized payments.

Developer Sandbox يحتاج حسابات أطفال مصطنعة

وفر test tenants وحسابات age bands وguardian roles وprivacy states، كي لا يطلب المطور اختبارًا على أطفال حقيقيين. اجعل بيانات sandbox مصطنعة وغير قابلة للمراسلة مع production. اختبر scopes وwebhooks وrevocation وage changes وblocks. لا تسمح API key sandbox بالعمل على production.

API Keys وClient Secrets ليست للواجهة العامة

تطبيق mobile أو JavaScript لا يستطيع حماية secret ثابت مثل خادم. استخدم public-client OAuth patterns وPKCE. لا تطلب من مطور وضع service secret داخل app يمكن استخراجه. إذا تسرب secret، rotate وراقب abuse ولا تعاقب المستخدمين بإغلاق حساباتهم.

Rate Limits يجب أن تراعي Child Harm لا Capacity فقط

حد 1000 طلب بالدقيقة قد يكون مقبولًا تقنيًا لكنه يسمح scraping social graph بسرعة. ضع limits حسب endpoint والactor والعمر والحساسية. راقب sequential IDs وenumeration وhigh fan-out. لا تكشف وجود child account عبر اختلاف error message.

Errors لا تكشف العمر أو الحماية

لا تقل هذا المستخدم عمره 12 لذلك رفضنا endpoint لتطبيق لا يحتاج العمر. استخدم error generic مثل action_not_permitted مع reason code داخلي أو user-facing آمن. developer الذي يحتاج فهم policy يمكنه قراءة docs لا بيانات فرد.

Developer Review ليس مرة واحدة

app قد يغيّر owner أو privacy policy أو business model أو scopes. أعد review عند طلب صلاحية جديدة أو زيادة استخدام أو incident أو تغيير ownership. اسحب unused scopes. لا تحتفظ approval 2019 كأنه يغطي منتجًا مختلفًا في 2026.

Remote Configuration قد يغير سلوك التطبيق

حتى من دون تحديث store، developer يستطيع تشغيل feature جديدة server-side. راقب API usage لا app version فقط. شروط المطور تمنع استخدام scope لغرض غير مراجع. anomaly detection يلتقط endpoint جديدًا أو زيادة تنزيل مفاجئة.

Compromised Developer App

إذا اختُرق خادم تطبيق موثوق، tokens الأطفال قد تصبح في خطر. وفر kill switch يسحب app tokens جماعيًا، وأبلغ users وفق الخطر. لا تعتمد على developer وحده ليبلغك. راقب leaked credentials ومعدلات abnormal API. بعد incident، أعد verification قبل إعادة الاتصال.

Revocation يجب أن تنتشر إلى Webhooks وCaches وJobs

إلغاء OAuth لا يكفي إذا توجد export job قيد التنفيذ أو webhook queue أو cache. اربط revocation بcentral authorization check، وألغِ jobs/subscriptions. لا تسمح للapp بقراءة export جاهز بعد فقد الصلاحية.

المستخدم يحتاج لوحة Connected Apps

اعرض اسم التطبيق والمطور وتاريخ الاتصال وما scopes الحالية وآخر استخدام، مع revoke بسيط. للقاصر، اشرح بلغة مناسبة. إذا guardian له دور، افصل ما يستطيع رؤيته أو سحبه حسب العمر والسياق. لا تجعل revoke مدفونًا في developer settings.

Age Transition يعيد تقييم Apps

عند تغير age band، لا تفتح scopes جديدة تلقائيًا لتطبيقات قديمة. أعد تقييم connections التي كانت restricted. وعند تصحيح العمر إلى أصغر، اسحب scopes غير المناسبة فورًا واطلب من developer حذف data التي لم يعد يحق له الاحتفاظ بها.

Delete Account يرسل Deauthorization Signal

عند حذف حساب، revoke tokens وwebhooks وjobs، وأبلغ التطبيقات ضمن mechanism موثق أن connection انتهت كي تحذف أو تعالج البيانات وفق الغرض والقانون. لا ترسل بيانات إضافية مع deauthorization. راقب completion للتطبيقات عالية الخطورة.

App Directory لا يساوي Endorsement

إذا تعرض المنصة apps approved، وضح معنى المراجعة ونطاقها. لا تستخدم شارة توحي أن التطبيق آمن للأطفال إذا راجعت فقط OAuth redirect. child-compatible label يحتاج criteria وتاريخ review. اسحب الشارة عند مخالفة أو expiry.

Transparency للمطورين والمستخدمين

انشر docs للscopes والقيود العمرية والretention وreporting. للمستخدم، اعرض app access. داخليًا، dashboard يجمع active child connections، high-risk scopes، unused tokens، incidents وdeveloper appeals. لا تنشر قائمة حسابات الأطفال أو تفاصيل تكشفهم.

اختبار Red Team للمنصة المطورية

1. Adult-only app يطلب child account.
2. Scope basic يحاول قراءة contacts.
3. Token قديم بعد revoke.
4. Webhook بعد age correction.
5. Bulk export social graph.
6. Message API إلى minor بلا relationship.
7. Location history request.
8. Compromised app credential.
9. Redirect URI manipulation.
10. Rate-limit enumeration.
11. Delete account with pending export.
12. Developer ownership transfer.

مقاييس

قِس child-connected apps، high-risk scopes، unused refresh tokens، revocation latency، webhook-after-revoke incidents، bulk exports، rate-limit abuse، developer violations، age-mismatch attempts، app compromises وdata deletion completion. لا تجعل API call volume نجاحًا بحد ذاته.

خطة 90 يومًا

30 يومًا: inventory endpoints/scopes/apps/age data. 31–60: developer verification، child scope policy، connected-app dashboard، revoke propagation. 61–90: sandbox personas، red team، webhook/export kill switch، developer re-review وmetrics. أغلق endpoints بلا owner أو غرض.

نموذج روافد المفاهيمي: السلسلة من Scope إلى أثر الطفل

تقترح روافد خمس حلقات: scope، actor، data/action، مدة الاتصال، وأثر الطفل. النموذج conceptual وغير متحقق. إذا كان scope حساسًا والمطور ضعيف الثقة والtoken طويلًا، تزيد الضوابط. يقاس بتقليل over-scoped apps وسرعة revoke وviolations.

ابدأ بنموذج صلاحيات لا بنموذج بيانات كامل

واجهة API موجهة لنظام يضم أطفالًا يجب أن تبدأ بالسؤال: ما أقل فعل يحتاجه التطبيق الخارجي، وما أقل بيانات لازمة لتنفيذ هذا الفعل؟ إعطاء تطبيق طرف ثالث ملف الطفل الكامل لأنه يحتاج اسم عرض فقط خطأ معماري. الأفضل تقسيم الصلاحيات إلى نطاقات دقيقة مثل قراءة اسم مستعار، إنشاء محتوى، قراءة قائمة محدودة، أو تنفيذ فعل واحد، مع فصل بيانات العمر والموقع والعلاقات والرسائل. كل نطاق يملك وصفًا مفهومًا للمستخدم ومسؤول النظام، ويجب ألا يؤدي قبول نطاق بسيط إلى منح نطاقات جديدة ضمنيًا. كما يفضل أن تعكس الرموز الممنوحة خصائص الحساب الحساسة مثل كونه حساب قاصر بطريقة لا تكشف تاريخ الميلاد نفسه، بحيث يستطيع الخادم تطبيق سياسة أكثر تحفظًا دون توزيع بيانات هوية إضافية على المطورين.

OAuth لا يحل مشكلة الموافقة إذا كانت الشاشة غامضة

قد يكون بروتوكول التفويض صحيحًا تقنيًا بينما تكون الموافقة سيئة عمليًا. شاشة تعرض «الوصول إلى حسابك» لا تشرح أن التطبيق سيقرأ قائمة الأصدقاء أو ينشر باسم الطفل. يجب ربط كل نطاق بفعل واضح وسبب، ومنع حزم صلاحيات ضخمة لا يمكن تفكيكها. في حسابات الأطفال يمكن وضع طبقة إضافية لبعض الأفعال عالية الأثر، لكن هذه الطبقة لا ينبغي أن تتحول إلى جمع وثائق أو بيانات أسرية غير ضرورية. والأهم أن تكون الموافقة قابلة للسحب بسهولة، وأن يظهر للمستخدم ما التطبيقات النشطة ومتى استخدمت الصلاحية آخر مرة، لا أن يختفي التفويض بعد أول نقرة.

مراجعة تطبيق الطرف الثالث قبل الوصول الفعلي

التسجيل كمطور ليس ضمانًا للسلوك. يحتاج النظام إلى مراجعة متناسبة مع المخاطر: هوية الجهة المطورة، الغرض المعلن، النطاقات المطلوبة، وجهات إعادة التوجيه، سياسة الاحتفاظ، الموردون الفرعيون، وخطة التعامل مع البلاغات. يمكن السماح بنطاقات منخفضة المخاطر في وضع محدود، بينما يتطلب الوصول إلى محتوى خاص أو وظائف مراسلة مراجعة إضافية واختبارًا. كما يجب منع تطبيق من تغيير غرضه بعد الاعتماد دون مراجعة؛ فإذا انتقل من أداة تعليمية إلى شبكة اجتماعية أو أضاف نموذج ذكاء اصطناعي خارجيًا، يعاد تقييم الصلاحيات والبيانات. الاعتماد هنا ليس ختمًا دائمًا، بل حالة قابلة للتعليق والسحب عند تغير المنتج أو ظهور إساءة.

الرموز المميزة والهوية: قلل ما يمكن نسخه وإعادة استخدامه

كل Token واسع وطويل العمر يرفع أثر التسرب. الحسابات الحساسة تستفيد من مدة أقصر، تدوير رموز التجديد، ربط بعض الأفعال بالسياق، ومنع استخدام الرمز من عميل غير مصرح به. لا تُحمل داخل الرمز بيانات لا يحتاجها المطور فقط لأنها متاحة في قاعدة المستخدمين. وعند الحاجة إلى تمييز سياسة قاصر يمكن استخدام Claim وظيفي محدود لا يسمح باستنتاج تفاصيل الميلاد. كما يفيد فصل رمز القراءة عن أفعال النشر أو الدفع، وطلب خطوة جديدة عند الانتقال إلى فعل أعلى أثر. عند الاشتباه بتسرب لا يكفي تغيير كلمة مرور الطفل إذا بقيت رموز التطبيقات الخارجية صالحة؛ يجب أن تملك المنصة قدرة على إبطالها بصورة انتقائية أو جماعية ومراجعة آخر استخدام.

Webhooks والأحداث قد تسرب أكثر من الاستعلامات

المطور قد لا يطلب بيانات مباشرة، لكنه يستقبل Webhook عند كل رسالة أو صداقة أو تغيير ملف. لذلك تُعامل الأحداث كمسار بيانات مستقل: ما الحدث الضروري، ما الحقول المرسلة، هل يحتاج Payload كاملًا أم معرفًا يمكن استبداله بطلب لاحق، وكم مرة يعاد الإرسال؟ يجب توقيع الرسائل، منع كشف محتوى حساس في سجلات وسيطة، وتحديد مهلة حذف لدى الطرف الثالث. وإذا سحب المستخدم التفويض ينبغي أن تتوقف الأحداث فورًا لا بعد انتهاء اشتراك طويل. كما يجب اختبار ما يحدث عند فشل endpoint؛ إعادة إرسال الحدث عشرات المرات إلى وجهة مخترقة قد يضاعف الضرر بدل تحسين الاعتمادية.

Rate limits يجب أن تعكس نوع الضرر لا تكلفة الخادم فقط

تحديد المعدل ليس أداة أداء فقط. قدرة تطبيق على البحث عن آلاف أسماء الأطفال، إرسال دعوات متكررة، اختبار معرفات الحسابات أو تنزيل قوائم كبيرة قد تخلق استغلالًا حتى لو تحمل الخادم الحمل. لذلك تختلف الحدود حسب العملية والحساب والمطور والسلوك، وتوجد حدود تراكمية تمنع توزيع الطلبات على عدة مفاتيح. وعند اكتشاف نمط غير طبيعي يكون الرد متدرجًا: خفض المعدل، تعطيل نطاق محدد، طلب مراجعة المطور، أو إيقاف التطبيق. ويجب أن تكون الاستثناءات الممنوحة لشركاء كبار موثقة ومراجعة، لأن الحجم التجاري لا يقلل خطر الوصول الواسع.

سلسلة الموردين في API: من استلم البيانات بعد المطور؟

قد يستدعي التطبيق الخارجي خدمات تحليلات أو ذكاء اصطناعي أو دعم فني تنقل البيانات إلى طرف رابع لا يعرفه المستخدم. لذلك يحتاج عقد المطور وإفصاحه إلى قائمة بالمعالجات الفرعية ذات الصلة، وما إذا كانت بيانات حسابات القاصرين تُرسل إليها. يمكن للمنصة منع فئات من البيانات من مغادرة بيئة المطور أو اشتراط موافقة مسبقة على مورد جديد. كما يفيد فحص مكتبات العميل وSDKs التي ترسل Telemetry تلقائيًا، لأن التسرب قد يحدث قبل وصول الطلب إلى API نفسه. عند إنهاء التطبيق يجب أن تشمل خطة الخروج النسخ لدى الموردين الفرعيين والنسخ الاحتياطية وفق جدول موثق، لا حذف قاعدة المطور الرئيسية فقط.

الاستجابة لحادث تطبيق خارجي

عند اكتشاف إساءة أو اختراق، تبدأ المنصة بتحديد التطبيق والنطاقات والرموز والبيانات التي كانت متاحة، ثم تحدد هل المشكلة في حساب واحد أم تصميم يسمح بالوصول الواسع. يمكن إبطال الرموز وتعطيل النطاق عالي الأثر مع إبقاء أجزاء منخفضة المخاطر إن كان ذلك يقلل تعطيل المستخدمين. يُحفظ سجل الطلبات الضروري للتحقيق مع تقييد الوصول إليه، ويُطلب من المطور وصف الاحتواء والحذف والموردين المتأثرين. إذا كانت هناك حاجة لإبلاغ المستخدمين، يجب أن تكون الرسالة محددة: ما نوع البيانات أو الفعل الذي تأثر، ما الذي أوقفته المنصة، وما الخطوات التي يحتاجها المستخدم. لا يكفي إرسال نص عام عن «حدث أمني» لا يساعد الأسرة على القرار.

لوحة قياس لحوكمة منصة المطورين

تقيس المنصة عدد التطبيقات النشطة التي تملك نطاقات حساسة، متوسط عمر الرموز، نسبة التطبيقات التي لم تستخدم نطاقًا طلبته، زمن سحب الصلاحية حتى توقف الطلبات، عدد الموردين الفرعيين المعلنين، ومعدل المخالفات بحسب نوع النطاق. كما يفيد قياس طلبات البحث الجماعي، محاولات تجاوز الحدود، ونسبة التطبيقات التي تغير غرضها أو ملكيتها. يجب ألا يقتصر النجاح على عدد المطورين أو حجم الاستخدام؛ الهدف هو أن يضيف النظام قيمة دون خلق قناة موازية تتجاوز ضوابط الحساب الأساسية. تراجع الاستثناءات دوريًا، ويُغلق الوصول غير المستخدم تلقائيًا أو بعد مراجعة، وتُستخدم نتائج الحوادث لتعديل نموذج الصلاحيات نفسه.

اختبار رجوع لكل تغيير في API

عند إضافة endpoint أو حقل أو Scope جديد، يُختبر حساب قاصر صناعي عبر سيناريوهات إيجابية وسلبية: هل يحصل التطبيق على الحقل من مسار قديم رغم منعه في الجديد؟ هل يؤدي خطأ في GraphQL أو Expansion إلى إرجاع كائنات إضافية؟ هل يمكن استخدام معرف عام للوصول إلى مورد خاص؟ هل تبقى البيانات في Cache أو Log بعد سحب التفويض؟ توثق النتائج في مصفوفة من المتطلب إلى الاختبار إلى الإصلاح، ويعاد الاختبار عند تغيير مكتبة التفويض أو بوابة API أو مخطط البيانات. بهذه الطريقة لا تصبح سياسة حماية الطفل وثيقة منفصلة عن الكود الذي ينفذها.

أسئلة شائعة

المصادر والمنهجية

تعتمد الصفحة على OAuth 2.0 Security Best Current Practice RFC 9700، وسياسات Google Play Families وApple Kids، وFTC COPPA، وICO Children’s Code، وeSafety Safety by Design، وWeProtect. تم دمج أمن البروتوكول مع حوكمة الطفل: scopes والعمر والمطور والبيانات والمدة وrevocation عبر API/webhooks/exports.

توثيق المطور يجب أن يشرح سياسة القاصر كعقد تقني

توثيق API الجيد لا يكتفي بقائمة endpoints. يوضح للمطور ما الذي يتغير عند حساب قاصر، أي Scopes غير متاحة، وما الأخطاء المتوقعة عند محاولة فعل محظور، وكيف يختبر ذلك في Sandbox. كما يجب أن تكون أمثلة الكود نفسها متوافقة مع أقل صلاحية بدل أن تطلب نطاقًا واسعًا لتبسيط الشرح. وعند تغيير سياسة العمر أو البيانات، يُصدر Changelog يحدد الأثر وموعد التطبيق ومسار الترحيل، مع مهلة لا تسمح ببقاء نسخة قديمة تتجاوز الضابط طويلًا. هذا يجعل سياسة الحماية جزءًا من عقد المنصة التقني ويقلل الأعطال التي يدفع ثمنها الطفل أو الأسرة.