محلي افتراضيًا
تقييم المخاطر والتحقق من challenge والتفويض تبقى داخل المشروع.
أمان مستضاف ذاتيًا · PRE-1.0
حماية من الروبوتات مع إبقاء قرار الثقة على خادمك.
يحمي 2IZI Guard النماذج والإجراءات العامة عبر تقييم محلي للمخاطر واحتكاك تكيفي ورموز تفويض خادمية أحادية الاستخدام، من دون CAPTCHA خارجية إلزامية.
لا يعتمد النواة إلزاميًا على Google أو Yandex أو Cloudflare أو API خارجي أو CDN أو قياس طرف ثالث.
PHP 8.1+AdaptiveShadow ModePrivacy-first
2IZI Guardlocal decision surface
actionregister
origin2iziguard.com
sessionbound
modeAdaptive
local risk18/100
PASSsilent
Context
Risk
Challenge
Token
Consume
0required third-party calls
256-bitopaque token
HMACstate integrity
1×atomic consume
0required outbound runtime calls
256-bitopaque token entropy
3×action / session / origin bound
1×atomic one-time consume
لحماية إجراءات التطبيق
الأمان قرار خادمي، وليس حالة أداة مرئية.
الاختبار المرئي مجرد طبقة. Guard يحمي الإجراء الخادمي قبل تشغيل العملية التجارية.
سلطة الخادم
نجاح JavaScript ليس تفويضًا. الخادم يتحقق من Guard token ويستهلكه.
احتكاك تكيفي
المرور الموثوق قد يمر بصمت، والمخاطر الأعلى قد تشغّل PoW أو hold أو throttle أو deny.
وعي بالسرعة
يمكن الجمع بين حدود الشبكة وGuard session والحساب وaction والسياق العام.
Privacy-first
لا نعتبر IP أو إشارات المتصفح هوية، ونتجنب fingerprinting العدواني افتراضيًا.
قرارات قابلة للتفسير
Risk Engine يحتفظ بـ reason codes وتوقعات Shadow Mode للضبط.
كيف يعمل
Action واحدة محمية. خمس نقاط تحقق مستقلة.
يمكن للمتصفح المشاركة في challenge، لكن الإذن التجاري يصدر ويُستهلك دائمًا على الخادم.
01
تحقق من السياق
Origin وaction وsession والحدود الأساسية قبل العمل المكلف.
02
قيّم محليًا
إشارات الخادم والتطبيق تنتج قرار مخاطرة قابلًا للتفسير.
03
أضف الاحتكاك
السياسة تختار PASS أو PoW أو interaction أو throttle أو deny.
04
أصدر مرة واحدة
Token عشوائي 256-bit مرتبط بـ session/action/origin وTTL قصير.
05
استهلك ذريًا
Endpoint التجاري يستهلك مرة واحدة ويرفض replay وmismatch وexpiry.
نموذج التهديد
نفترض أن المهاجم يعرف كامل الشفرة.
يمكن أن تكون الشفرة وJavaScript وAPI ومخطط DB وPoW والحدود معروفة؛ الأسرار والتفويض يبقيان على الخادم.
نفترض أن المهاجم لديه
- الشفرة الكاملة
- نماذج AI حديثة
- Playwright / Selenium / headless Chromium
- Residential proxies
- تسجيلات لحركته الخاصة
الأمان لا يعتمد على إخفاء
- JavaScript
- خوارزمية challenge
- أسماء الحقول
- endpoints
- risk thresholds
مفتوح المصدر
يجب أن يزيد المصدر العام قابلية التدقيق لا أن يضعف النموذج.
قراءة التنفيذ لا يجب أن تمنح authorization bypass. المراجعة العامة تحتاج releases منضبطة ومفاتيح وصلاحيات repository وسياسة ثغرات.
يُنشر
- المصدر وسجل التغييرات
- SECURITY.md وresponsible disclosure
- threat model والبنية
- اختبارات security / red-team آلية
- checksums وrelease notes
يبقى خاصًا
- production config/guard.php
- APP_KEY ومفاتيح HMAC/privacy/rate-limit
- DB dumps وsecurity events حقيقية
- cookies/tokens/sessions حقيقية
- أسرار النشر وتفاصيل البنية الخاصة
التكامل
سطح تكامل صغير. الإذن النهائي يبقى على الخادم.
النواة الحالية تستهدف PHP 8.1+ ومستقلة عن framework عند حدود الأمان. احمِ كل action صراحة واستهلك token قبل العملية التجارية.
Actions شائعةloginregisterpassword_resetcontactcheckoutfile_upload
FrontendHTML
<script src="/guard/public/assets/guard.js" defer></script> <form data-guard-action="contact"> … </form>
Action محميةPHP
$result = Guard::verifyAndConsume( $_POST['guard_token'] ?? '', 'contact' ); if (!$result->allowed()) { http_response_code(403); exit; }
PRE-1.0
الحالة الحالية
0.4.10 · pre-1.0 · تطوير نشط
الفرع الحالي security-first مع اختبارات regression/red-team آلية. ابدأ بـ Shadow Mode ثم اضبط enforcement على حركة حقيقية.
PHP coreمتاح
Webasyst / Shop-Script adapterبعد استقرار النواة
Verified agents / Privacy Passمستقبل / يعتمد على المعايير
Release0.4.10
الأسئلة الشائعة
ادعاءات واضحة. حدود واضحة.
هل المصدر العام يجعل Guard أسهل للكسر؟+
يجعل التنفيذ أسهل للدراسة، لذلك لا يجوز أن يعتمد الأمان على الغموض. المراجعة العامة والاختبارات تساعد في اكتشاف العيوب مبكرًا.
هل Guard بديل لـ MFA أو passkey أو WAF؟+
لا. Guard طبقة anti-automation وabuse-protection. الإجراءات الحرجة ما زالت تحتاج مصادقة وتفويض وCSRF وMFA/passkey وضوابط بنية.
هل تحتاج النواة إلى الإنترنت؟+
مسار الحماية الأساسي لا يحتاج طلبات outbound إلزامية. التحديثات والمستودع وattestation الاختياري منفصلة.
هل يستطيع bot متقدم اجتياز الفحص التفاعلي؟+
نعم. Browser متحكم به أو AI أو human solver قد يقلد التفاعل. التفويض النهائي يبقى مع سياق الخادم والحدود وtokens وسياسات الأعمال.
أنشئ حماية من إساءة الاستخدام يمكن تدقيقها.
تشغيل محلي. تفويض خادمي. نموذج تهديد علني. بلا CAPTCHA خارجية إلزامية.