डिफ़ॉल्ट रूप से local
Risk evaluation, challenge verification और authorization प्रोजेक्ट के अंदर रहते हैं।
SELF-HOSTED SECURITY · PRE-1.0
बॉट सुरक्षा जिसमें trust decision आपके अपने सर्वर पर रहता है।
2IZI Guard स्थानीय risk evaluation, adaptive friction और single-use server authorization tokens से forms और public actions की सुरक्षा करता है। External CAPTCHA runtime अनिवार्य नहीं है।
Core runtime को Google, Yandex, Cloudflare, external API, CDN या third-party telemetry की अनिवार्य आवश्यकता नहीं है।
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
Application actions के लिए
Security एक server decision है, widget state नहीं।
Visible challenge केवल एक layer है। Guard business operation से पहले server action को protect करता है।
Server authority
JavaScript success authorization नहीं है। Server Guard token को verify और consume करता है।
Adaptive friction
Trusted traffic चुपचाप गुजर सकता है; अधिक risk पर PoW, hold, throttle या deny लागू हो सकता है।
Velocity-aware
Network, Guard session, account, action और site-wide limits को जोड़ा जा सकता है।
Privacy-first
IP और browser signals पहचान नहीं हैं; invasive fingerprinting default में बंद है।
Explainable decisions
Risk Engine tuning के लिए reason codes और Shadow Mode predictions रखता है।
कैसे काम करता है
एक protected action. पाँच independent checkpoints.
Browser challenge में भाग ले सकता है, लेकिन business permission हमेशा server जारी और consume करता है।
01
Context validate
महंगे काम से पहले Origin, action, session और basic limits जाँचें।
02
Local score
Server और application signals explainable risk decision बनाते हैं।
03
Friction जोड़ें
Policy PASS, PoW, interaction, throttle या deny चुनती है।
04
एक बार issue
Random 256-bit opaque token को session/action/origin और short TTL से bind करें।
05
Atomic consume
Business endpoint token को एक बार consume करता है; replay, mismatch और expiry reject होते हैं।
Threat model
मानते हैं कि attacker पूरे codebase को जानता है।
Source, JavaScript, API, DB schema, PoW और thresholds ज्ञात हो सकते हैं; secrets और authorization server-side रहते हैं।
मानते हैं attacker के पास है
- पूरा source code
- modern AI models
- Playwright / Selenium / headless Chromium
- residential proxies
- अपने traffic captures
Security इन चीज़ों को छुपाने पर निर्भर नहीं
- JavaScript
- challenge algorithms
- field names
- endpoints
- risk thresholds
Open source
Public code auditability बढ़ाए, model को कमजोर न करे।
Implementation पढ़ना authorization bypass नहीं बनाना चाहिए। Public review के लिए disciplined releases, keys, repository permissions और vulnerability handling जरूरी हैं।
Publish करें
- source और change history
- SECURITY.md और responsible disclosure
- threat model और architecture
- automated security / red-team tests
- release checksums और notes
Private रखें
- production config/guard.php
- APP_KEY और HMAC/privacy/rate-limit keys
- DB dumps और real security events
- real cookies/tokens/sessions
- deployment secrets और private infrastructure
Integration
छोटी integration surface. अंतिम permission server पर रहती है।
Current core PHP 8.1+ को target करता है और security boundary पर framework-independent है। हर action को explicit protect करें और business operation से पहले token consume करें।
Typical actionsloginregisterpassword_resetcontactcheckoutfile_upload
FrontendHTML
<script src="/guard/public/assets/guard.js" defer></script> <form data-guard-action="contact"> … </form>
Protected actionPHP
$result = Guard::verifyAndConsume( $_POST['guard_token'] ?? '', 'contact' ); if (!$result->allowed()) { http_response_code(403); exit; }
PRE-1.0
Current status
0.4.10 · pre-1.0 · active development
Current branch में security-first architecture और automated regression/red-team coverage है। पहले Shadow Mode, फिर real traffic पर enforcement tune करें।
PHP coreAvailable
Webasyst / Shop-Script adapterCore stabilization के बाद
Verified agents / Privacy PassFuture / standards-dependent
Release0.4.10
FAQ
स्पष्ट दावे. स्पष्ट सीमाएँ.
क्या public source Guard को तोड़ना आसान बनाता है?+
Implementation को study करना आसान होता है, इसलिए security obscurity पर निर्भर नहीं हो सकती। Public review और tests defects जल्दी ढूँढने में मदद करते हैं।
क्या Guard MFA, passkey या WAF को replace करता है?+
नहीं। Guard anti-automation / abuse-protection layer है। Critical actions को authentication, authorization, CSRF, MFA/passkey और infrastructure controls अभी भी चाहिए।
क्या core runtime को Internet चाहिए?+
Core protection flow को mandatory outbound request नहीं चाहिए। Updates, repository और optional attestation अलग हैं।
क्या advanced bot interactive check पास कर सकता है?+
हाँ। Controlled browser, AI या human solver interaction की नकल कर सकते हैं। Final authorization फिर भी server context, limits, tokens और business policy पर निर्भर है।
ऐसी abuse protection बनाएं जिसे audit किया जा सके।
Local runtime. Server authorization. Public threat model. Mandatory external CAPTCHA नहीं।