Security & Trust
Security is the product.
Not an afterthought.
Anti Social Engine is built specifically to stop security failures. Everything in the architecture reflects that purpose — from immutable audit logs to isolated challenge flows.
Core Security Principles
Immutable audit logging
Every event, every response, every decision is written to PostgreSQL immediately and immutably. No in-memory state. No ephemeral session data. Every checkpoint action is timestamped, actor-attributed, and stored with full metadata.
Server-side validation at every step
The intent check, OTP submission, and outcome decisions are all validated server-side. The client cannot manipulate outcomes. Challenge page state is checked against the database on every API call. Nothing is trusted from the browser.
Isolated challenge environment
The hosted challenge page is a completely separate, server-rendered environment. No JavaScript is injected into your frontend by default. An optional embedded Web SDK is available for popup mode — the isolation boundary is architectural, not policy-based.
Tamper-resistant flows
Session state cannot be skipped. The intent check must complete before an OTP is issued. The OTP must be validated before the session resolves. The API enforces sequencing — violating it returns an error, which is logged.
Attempt tracking and throttling
OTP attempts are tracked per session. Maximum attempts are enforced. Each invalid attempt is logged. When the limit is reached, the session is resolved as block_escalate automatically. Rate limiting applies at the API layer.
No required frontend dependency
Anti Social Engine requires zero changes to your frontend by default. The challenge flow is fully hosted. Your platform redirects the user, or uses the optional embedded Web SDK for popup mode. Either way, the security posture of the challenge cannot be degraded by a frontend bug, XSS, or supply chain attack on your stack.
Architecture Layers
Data layer
PostgreSQL via Supabase. All session, event, response, and audit data persists immediately on write. No eventual consistency risk on security-critical state.
API layer
Next.js API routes with server-side Supabase client (admin key). No client-side database access. All mutations are authenticated and logged.
Challenge layer
Server-rendered, isolated page. State is fetched from the database on load. Session ID in URL is validated against the checkpoint_sessions table. Resolved sessions return an already-resolved state.
Connector layer
Platform-specific code is confined to thin connectors. Connectors normalize events and call the shared API. No connector can modify the risk engine or audit system.
Verification layer
The intent check answer and OTP submissions are validated server-side. OTP codes are generated and stored server-side — no secret is ever sent to the client. Codes expire and have attempt limits enforced in the database. A signed decision token is issued on session resolution and verified server-side by the customer backend.
Data & Privacy
Data persistence
All session data, audit logs, and responses are stored in a dedicated PostgreSQL database. Data is never cached in memory or stored in cookies beyond session routing.
Minimal data collection
Anti Social Engine collects only what is necessary for verification: user ID, event context, IP, user agent, and verification responses. No behavioral tracking beyond the checkpoint session.
Enterprise data handling
Enterprise plans include DPA support, custom data retention policies, and dedicated infrastructure. SOC 2 documentation available on request.
Security disclosures
Found a vulnerability? We take security reports seriously and respond within 48 hours.