Protected sign-in
Email/password auth uses normalized identifiers, generic credential errors, throttled failures, signed HTTP-only session cookies, and server-verified Cloudflare Turnstile when production secrets are configured.
Security posture
Security controls for the AI builder radar.
HypeDar is built with layered controls for accounts, Pro entitlements, checkout, provider webhooks, generated content, and browser-facing routes. This page is a public summary of the controls we actively maintain; it is not a guarantee that no vulnerability can exist.
Current assurance
Important layers are enforced server-side.
We do not rely on UI state for paid access, billing status, or abuse protection. Sensitive provider credentials stay in private runtime configuration, payment card handling stays with the payment provider, and webhook events must verify before they can change entitlement state.
- Auth, billing, webhook, entitlement, Turnstile, redirect, and sanitizer regression tests run in the unit suite.
- Provider raw/error payloads are kept out of browser JSON responses.
- Provider API base URLs must parse as HTTPS before credentials are sent.
- Cross-origin browser mutations are blocked for checkout, portal, analysis, engagement, login, and signup flows that use mutation guards.
Account and Pro access gates
Paid surfaces check the current session and entitlement on the server. Client-supplied user IDs, email addresses, usage counters, and plan state are not trusted for privileged actions.
Safer checkout handoff
Checkout and customer-portal routes require authentication, same-origin mutation checks, HTTPS-only provider redirects, sanitized client responses, and explicit opt-in before using emergency live product fallbacks.
Signed billing webhooks
Creem webhooks require HMAC verification, event-id idempotency, database-bound writes, and a body-size limit before payload processing.
Generated content boundary
Premium generated HTML is treated as untrusted and sanitized at the API boundary before browser insertion. Public client rendering paths use escaping or textContent for user-visible data.
Browser security headers
Responses include nosniff, frame denial, strict referrer policy, restrictive permissions policy, COOP, HSTS on HTTPS, and CSP report-only coverage for script/frame/connect sources.
What we do not claim
No public website can honestly claim perfect security. HypeDar’s security posture is defense-in-depth: reduce realistic abuse, fail closed around payments, keep secrets out of the browser and repository, and verify sensitive state changes on the server.
Report a concern
If you find a vulnerability or account/billing issue, email support@hypedar.dev. Include the affected URL, steps to reproduce, and impact. Do not include secrets, personal data, or destructive payloads in the report.