Security

WRNexusJS provides primitives for CSP, CSRF, Trusted Types, sessions, validation, authorization, encryption, upload restrictions, request limits, and WebSocket-origin checks. Applications remain responsible for correct configuration, business authorization, secrets, dependencies, data protection, and operations.

Start with a production policy

The following baseline blocks framing, restricts referrers and cross-origin access, enables CSRF and Trusted Types, and caps request bodies. Replace the example origin with the exact browser origin that calls your application.

// wrnexus.config.ts
export default {
  security: {
    contentSecurityPolicy: true,
    csrf: true,
    trustedTypes: true,
    frameOptions: "deny",
    referrerPolicy: "strict-origin-when-cross-origin",
    cors: { origins: ["https://app.example.com"], credentials: true },
    requestLimit: { maxBytes: 1_048_576 },
  },
};

What you can change

• Add only required API origins to CORS; never use a wildcard with credentialed requests.
• Lower request limits for JSON APIs and define separate upload limits for accepted file types.
• Extend CSP only for origins your application actually loads; avoid unsafe inline script exceptions.
• Enable HSTS only after HTTPS works on every production hostname and subdomain you include.
• Set session expiry, rotation, secure, HTTP-only, and SameSite behavior for your authentication flow.

Verify the resolved controls

bunx wrnexus config . --explain --profile=production
bunx wrnexus security audit .
bunx wrnexus typecheck .
bunx wrnexus build .

Review the resolved production configuration, then test a valid request, an invalid CSRF token, an oversized body, an unapproved origin, an anonymous protected request, and a permission-denied request. Security configuration is complete only when denial behavior is tested.

Supported releases

Only the current private-preview release 0.8.7 is documented here. A formal old-release support window is not yet published.

Report a vulnerability

Use WorkRoot’s approved private contact path at workroot.in. Do not publish exploit details or secrets. Include affected version, impact, reproduction, and a safe contact method. Response targets, encryption key, bounty, audit, and certification are not currently claimed.

Deployment controls

Terminate TLS at a trusted edge, forward only expected proxy headers, store secrets outside source control, apply database migrations before traffic, and monitor rejected requests without logging credentials. Continue with the complete application security guide.