Help for Clients and operators

Runtime Application Self-Protection. Security that runs inside the Client app at launch and in session — Detect → Decide → Enforce — before protected UI. On AppDefender.dev that control is the Launch Security Gate on mobile and the session gate on web.

A WAF sits on the network. MDM sits on the device profile. RASP sits in the app runtime. The Launch Security Gate on mobile and the session gate on web still decide ALLOW, RESTRICT, or BLOCK even when the user already has a token or cookie.

No. A valid access token never overrides BLOCK. The Launch Security Gate decides before protected UI. That rule is RASP-AUTHZ-001 and it is the same in Sandbox and Production.

Offline Threat Handling uses a signed cached policy plus local sensors. Missing or rejected crypto policy fails closed. A rooted handset with a valid token is still BLOCK.

Yes. Two surfaces, one control plane. Mobile Apps gate before Client UI. Web Apps gate before protected pages. Catalogs and environments stay isolated.

No. Android has 44 rules. iOS has 23. They stay isolated. A device block is one handset, not the whole Client app.

Native Android Keystore or iOS Keychain after AppDefender ALLOW. Super Admin vaults Client SDK secrets with envelope encryption. The app receives a signed KP1 token. React Native never receives the AES key. Release is denied after BLOCK.

Client Admin has four seats: Maker 1, Maker 2, Checker 1, Checker 2. Production policy needs two checkers. A maker cannot approve their own change.

No. On a Client web app, DevTools is a risk signal in the session gate. The browser that must render the page can still show JSON in Inspect. That is not a product defect and not a claim that the Network tab is hidden.

Request access on the contact form. Super Admin creates the workspace and enables Sandbox. Production stays closed until Super Admin opens it.

Country is mandatory from the master list. If you choose India, state or union territory is also required so Super Admin can place the workspace request.

Privacy Policy is /privacy. Terms & Conditions are /terms. Blog and newsroom RSS feeds are on /feeds.

Write to hello@AppDefender.dev. Use AppDefender.dev for the product and AppDefender Cyber Security Private Limited for the studio.

The Client app calls AppDefender.auth.requestOtp with a public App ID, phone, and purpose. The API generates the code, stores a hash, and sends SMS through DLT after it resolves PE ID, header, and template on the server. The SDK must not send a PE ID, template ID, or SMS key. OTP on a compromised handset is still not enough — the Launch Security Gate can BLOCK.

In Super Admin and Client Admin, not in the mobile or web SDK. Principal Entity ID is a string up to 32 characters — never BIGINT and never assumed to be 16 digits. Jio PE IDs can be 19 digits. Headers, templates, and SMS provider secrets stay in the backend with Maker–Checker before Production.

SMVDefender is AppDefender identity verification beside SMS OTP and SMSV. Use that name only — never AppSMV. It is an App Security module. Remote policy chooses SMS OTP, SMSV, or SMVDefender without an SDK rebuild.

Signed Client packages are @appdefenderdev/sdk.* only. Super Admin sends the private .npmrc and a read token. Use npm install or yarn add. Never use legacy @appdefender/* names.

Two isolated environments. Super Admin enables Sandbox first so Makers can prove FAIL paths. Production is a second catalog. Credentials, bind records, and ThreatDesk reports never mix. Production policy still needs two checkers.

ALLOW continues to authentication and protected UI. RESTRICT limits the session to permitted functionality. BLOCK shows the security screen, closes the app, and writes a ThreatDesk report. A token, OTP, or cookie cannot override BLOCK.

Super Admin grants the workspace, enables Sandbox then Production, owns default catalog actions, and publishes advisories. Client Admin operates four seats on that Client only. Super Admin and Client Admin never share a mixed catalog.

Unanswered questions are captured for the Security Team. Super Admin reviews the miss, writes the official FAQ, then approves it. Only after that publish step can Pro.AI use the record. Drafts never reach the public assistant, and Pro.AI does not invent an answer from the unanswered list.