Language

Security

Security in Zornux is a language-level capability, not a web add-on. Trust rules and authorization are enforced by the runtime itself, so every program — not just controllers — gets the same guarantees.

Three built-in defenses

Authorization

A restrict to <Role> guard runs before the block it protects. The runtime checks the current security context; if the role (or permission) is missing, the otherwise branch decides what happens — and the protected code never runs.

controller Products at "/products"
    require role "admin"

    on POST "/" with request_data
        add request_data to products
        give back created message "Product created!"
    end
end

Untrusted input is its own type

Data arriving from outside your program is UntrustedText. You can show it, but you cannot combine it with trusted Text using + — the classic injection vector — until you explicitly clean it. Crossing that line raises ZX1205 at runtime, turning "remember to sanitize" into a rule the language enforces.

create comment = untrusted(read_text("comment.txt"))

# show "New comment: " + comment   # error ZX1205 — untrusted + trusted

create safe = sanitize(comment)     # strips dangerous characters → Text
show "New comment: " + safe         # fine — 'safe' is trusted now

The trust-aware built-ins

Authentication providers

Attach an authentication provider declaratively with secure … using. The provider name must be registered, or you get ZX1206. Zornux ships an in-memory SimpleAuthentication provider; the abstraction is shaped so real providers (passkeys, API keys, LDAP) slot in without changing your program.

secure my_app using SimpleAuthentication

Native authentication toolkit

Beyond delegated sign-in, the auth module carries the pieces of an authentication system you'd otherwise bolt on — in-process, deterministic, and constant-time where it matters.

TOTP multi-factor

auth.totp_secret mints a Base32 secret, auth.totp_uri builds the provisioning URI an authenticator app scans, auth.totp_code produces the current code, and auth.verify_totp checks a submitted one — RFC 6238, with a small clock-drift window.

import auth

# Enrollment — a per-user secret and a URI the authenticator app scans.
public function enroll
    create secret = auth.totp_secret()
    create uri = auth.totp_uri(secret, "ada@example.com", "Zornux")
    give back secret
end

# Login step two — verify the 6-digit code.
public function verify_second_factor with secret, submitted_code
    give back auth.verify_totp(secret, submitted_code)
end

Sessions, bearer tokens, and refresh

auth.sign_in establishes the principal. In a serve app a JWT or session cookie is verified (HS256, constant-time) and bridged into the request's security context via the auth_bearer_secret setting, so restrict, policies, and claim(...) see the real caller. Refresh-token rotation keeps the rotated-away token as a tombstone and revokes the entire session family if a superseded token is ever replayed — the OWASP reuse defence, on by default.

Policies & claims

For authorization that's more than a single role, Zornux has first-class policies: a policy … end block names a set of require rules (authentication, roles, permissions, claims, even other policies), and resource-based check blocks decide with ordinary code. They're enforced with the same guard — restrict to policy Name otherwise … — and they fail closed.

policy CanManageOrders
    require authentication
    require role "Manager" or "Owner"
end

restrict to policy CanManageOrders otherwise give back status 403

See the dedicated Authorization page for claims, custom check blocks with the injected user, resource-based policies, and automatic denial logging.

Memory safety

Zornux is memory-safe by design. There are no pointers, no manual memory to allocate or free, and no way to reach an address or read past the end of a list — so whole classes of bugs simply can't be written. Values are managed for you, and when a program pushes a real limit it stops with a clear, located message instead of crashing.

function descend with n
    give back descend(n + 1)     # runaway recursion
end

try
    show descend(1)
catch error
    show "stopped safely"        # the program keeps control
end

Checking for weaknesses

Beyond the guarantees above, zornux check --security reads your program the way a reviewer would and reports what it finds: a secret written into the source, untrusted data reaching a query or a command, a resource opened and never closed, a route that changes data with nothing guarding it, a cookie giving up a safe default. Each finding explains itself and suggests a fix. It's opt-in, so an ordinary check is unchanged.

Auditing your dependencies

Point it at an advisory feed and it will also tell you when a package you depend on has a known vulnerability. The feed is a file you supply — the compiler never reaches the network to fetch one.

zornux check app.zx --security --advisories advisories.json

Advisories are matched against the versions your project actually resolved, including packages you depend on only indirectly. Your project is found by looking upward from the file you checked, so the same versions are read wherever your program lives.

The audit fails closed, because an audit that quietly skips something is worse than no audit at all. A dependency whose version isn't resolved yet is reported as not audited — never as safe; run zornux restore first, and it will be checked like the rest. An advisory written in a way the check cannot read is named in the output and stops the check, rather than passing the package it was meant to catch. An advisory whose severity is unrecognized is treated as an error, never quietly downgraded.

For the formal rules behind these guarantees, see the Specification and the Diagnostics catalog (ZX1200–1299).