# Vexlora High Security Architecture

Vexlora v1.0.0 adds a frontend security architecture and buyer-facing Security Center. It improves the template's defensive defaults while clearly separating what the frontend can enforce from what a production backend/infrastructure must enforce.

## Security Center routes

- `/security` — security posture and control matrix
- `/security/authentication` — MFA/password/session/SSO-ready policies
- `/security/file-security` — upload policy and scan/quarantine states
- `/security/input-protection` — validation, rendering and revalidation rules
- `/security/api-webhooks` — API and webhook security
- `/security/browser-security` — CSP and response headers
- `/security/events` — security event stream
- `/security/policies` — buyer-facing deployment baseline

Existing session and device pages remain under Account Security and are linked rather than duplicated.

## File upload boundary

The shared FileUpload component now performs frontend preflight checks:

- allowed extension/type rules
- file size limits
- suspicious double-extension rejection
- executable/script extension blocking
- archive blocking by default
- explicit warning that server-side type verification and malware scanning are still required

Browser checks are not presented as antivirus or as a trusted security boundary. Production applications should upload to a trusted server/storage service, normalize filenames, verify content/type, scan or quarantine files, authorize uploaders, and publish only after a clean verdict.

## Form and input protection

Vexlora continues to use React Hook Form + Zod for typed validation and now standardizes destructive error styling on text, textarea, select, checkbox and switch controls when `aria-invalid` is present.

Production mutation/API handlers must repeat validation on the server. React's escaped rendering should be preserved, and untrusted raw HTML must not be rendered directly without a trusted sanitization layer.

## Browser security defaults

`next.config.ts` centrally configures:

- Content-Security-Policy
- X-Content-Type-Options: nosniff
- Framing policy: CSP `frame-ancestors` allowlist (`self` + ThemeForest preview by default; optional trusted origins through `VEXLORA_FRAME_ANCESTORS`)
- `X-Frame-Options: DENY` is intentionally not emitted because it would override/block the approved cross-origin marketplace preview in supporting browsers.
- Referrer-Policy
- Permissions-Policy
- Cross-Origin-Opener-Policy

The CSP intentionally remains compatible with the current frontend template. Buyers with a fully dynamic Next.js deployment can harden it further using nonce-based CSP after integrating their own server/runtime constraints.

## API and webhook security

The UI documents these production requirements:

- HTTPS only
- secrets kept out of browser bundles
- authorization at every sensitive action
- webhook signature/timestamp verification
- replay protection
- CSRF/origin protection where cookie authentication is used
- rate-limiting adapters for high-risk endpoints
- correlation/audit IDs for sensitive actions

## Frontend-only scope

Vexlora is a frontend admin template. It does not claim to provide a malware engine, database authorization layer, WAF, server rate limiter, secret vault or production identity provider. The Security Center exposes the correct contracts and integration points so buyers can connect those protections without redesigning the admin UI.