Security hardening: NIST passwords, CSP, safe deserialization

Secure by default

The wikantik-http module is a dedicated servlet filter chain that sits in front of every request. CSRF protection, CORS, Content Security Policy, and a standard set of security headers are active without any configuration. There is no "enable security mode" switch to forget to flip.

This section covers each hardening layer: what it is, how it is implemented in Wikantik, and what threat it addresses.

Passwords done right: NIST 800-63B

NIST Special Publication 800-63B is the US government's digital identity guideline. Its key insight is that the password rules that organizations traditionally enforced — mandatory rotation every 90 days, required special characters, maximum length restrictions — actually make passwords weaker, not stronger. Users respond to burdensome rules with predictable patterns: Password1!, Summer2024#.

Wikantik's password validation follows the current NIST guidance:

• Minimum length is enforced.
• Common-password blocklist — new passwords are checked against a list of known breached and trivially guessable passwords. password, 123456, and their obvious variants are rejected.
• Mandatory rotation and arbitrary complexity rules are not enforced — NIST explicitly recommends against them.

This means your team's passwords are longer and more unique in practice, because they weren't forced into a corner by rules that reward gaming the system.

No default credential past first login

The most common way a self-hosted application gets compromised isn't an exotic exploit — it's a shipped default password that nobody changed. Wikantik closes that gap by construction. A fresh install seeds exactly one account, and that account is flagged so its first login requires choosing a new password before anything else works.

Until the password is changed, a MustChangePasswordFilter gates /api/* and /admin/* with 403 PASSWORD_CHANGE_REQUIRED, exempting only the auth surface needed to fix the situation. The replacement is validated against the same NIST 800-63B rules and blocklist as any other password, so the seeded default cannot simply be re-chosen. The net effect: no Wikantik deployment runs with a known default credential past initial setup.

Deserialization filtering

Java deserialization vulnerabilities have enabled remote code execution in countless Java applications over the past decade — not because the applications were poorly written, but because Java's ObjectInputStream will inflate any class on the classpath if you ask it to, and a sufficiently clever chain of objects can trigger arbitrary code execution.

Wikantik applies ObjectInputFilter whitelists to every ObjectInputStream usage. Only an explicit allowlist of classes can be deserialized. Any attempt to deserialize a class outside the allowlist is rejected before the object is constructed. This closes the gadget-chain attack surface at the JVM level, independent of what's on the classpath.

CSRF, CORS, CSP, and security headers

The wikantik-http servlet filter chain applies the following on every response:

CSRF — synchronizer token pattern

State-changing requests (POST, PUT, DELETE) must carry a valid session-bound CSRF token. The token is generated per session and checked before any mutation proceeds. The one explicit exception is the SAML /sso/callback endpoint: the IdP-signed SAML assertion is its own CSRF defense (an attacker cannot forge a valid IdP signature), so a synchronizer token would add friction without adding security.

CORS

Cross-Origin Resource Sharing headers are set to restrict which origins can make credentialed requests to the API. The CORS filter is configurable and defaults to denying cross-origin credentialed requests unless explicitly allowed.

Content Security Policy

A Content Security Policy header is sent with every HTML response, restricting which origins scripts, styles, and other resources can be loaded from. CSP is the primary defense against XSS attacks that manage to inject content — even if an attacker injects a <script> tag, the browser refuses to execute it if the source doesn't match the policy.

Standard security headers

Additional headers applied on every response include:

• X-Content-Type-Options: nosniff — prevents MIME-type sniffing
• X-Frame-Options: SAMEORIGIN — blocks clickjacking
• Referrer-Policy — controls referrer leakage
• Strict-Transport-Security — enforces HTTPS on compliant browsers

Session management

Wikantik rotates the HTTP session on every authentication event — both local password login and SSO callback. The old session ID is invalidated and a fresh one is issued before any privileged state is written. This closes the session fixation attack, where an attacker tricks a user into using a pre-seeded session token.

Authentication is JAAS-based. Pluggable login modules support local database, LDAP, SSO (pac4j), and container-managed authentication. All modules coexist and can be active simultaneously.

Defense in depth

The hardening described here is one layer of a broader stack. For a complete picture, see:

• SSO (SAML / OIDC) — session rotation, fail-closed account binding, CSRF handling for SAML
• RBAC & access control — JAAS permissions, policy grants, page ACLs
• Tamper-evident audit log — every authentication event, access denial, and admin action recorded and verifiable
• SCIM provisioning — deactivation enforced at every login path; SCIM groups never grant Admin

Frequently asked questions

What is NIST 800-63B password validation?

NIST SP 800-63B is the US government's digital identity guideline. Its password rules focus on real-world security: minimum length matters, complexity rules don't. Wikantik enforces a minimum length requirement and checks new passwords against a common-password blocklist. Mandatory rotation and special-character rules are not enforced, as NIST 800-63B explicitly recommends against them.

How does Wikantik protect against CSRF attacks?

The wikantik-http module includes a CSRF servlet filter that implements the synchronizer-token pattern: every state-changing request must carry a valid session-bound token. The one exception is the SAML /sso/callback endpoint, which is exempt because the IdP-signed SAML assertion is its own CSRF defense.

What is deserialization filtering and why does it matter?

Java deserialization vulnerabilities have been the source of critical remote code execution exploits in many Java applications. Wikantik applies ObjectInputFilter whitelists on all ObjectInputStream usage, restricting which classes can be deserialized to an explicit allowlist. This closes the attack surface for gadget-chain exploits against any serialized data Wikantik processes.