Hardened Runtime Isolation, Sandboxing, and Web Vulnerability Defenses
WebForge is architected with a security-first posture to prevent common web and software supply-chain vulnerabilities by design.
TechScript executes code within a strict capability model. An application cannot access sensitive system resources unless explicitly granted in techscript.toml:
[config]
capabilities = [
"Network", # Permits HTTP client and server sockets
"FileSystem" # Restricts file I/O to project directory only
]If code attempts unauthorized operations (such as inspecting system passwords or spawning unsanctioned processes), the runtime halts with a capability violation error.
The WebForge static file server and module resolver enforce canonical path resolution:
- All file access requests are resolved relative to designated directories (
public/,dist/). - Queries containing
../, null bytes, or URL-encoded equivalents (%2e%2e%2f) are immediately rejected with403 Forbiddenor400 Bad Request.
All database interactions generated by WebForge use parameterized statements (rusqlite::params![]):
- Dynamic form inputs are never concatenated directly into raw SQL.
- Table and column names are validated against compile-time AST schemas.
- All user-supplied text rendered via
show textorshow headingis automatically HTML-escaped. - Content-Security-Policy (CSP) headers are provided by the embedded server to restrict unsanctioned script execution.
- TechScript packages do not run arbitrary pre-install or post-install shell scripts.
- Every installed dependency is pinned to an exact SHA-256 checksum in
techscript.lock. - Tampered or mismatched package archives fail verification immediately.