Turbine includes a multi-layered in-process security sandbox written entirely in Rust that runs inside the same process as the HTTP server, with ~500 ns total overhead per request. There is no external WAF, no ModSecurity, no additional network hop.

The examples/raw-php/security-demo example ships an interactive browser UI with pre-built attack payloads for every guard:

cd examples/raw-php/security-demo
turbine serve
# open http://localhost:8083/

The demo page lets you pick any attack from a dropdown (SQL injection, code injection, obfuscation chains, behaviour attacks), send it with GET or POST (JSON / form-encoded), and watch the HTTP 403 response with the matched pattern — PHP never executes.

Turbine's security operates in 5 layers (called "Camadas"):

Request → [Layer 1: Execution Whitelist]
        → [Layer 2: Data Directory Guard]
        → [Layer 3: Path Validation]
        → [Layer 4: Heuristic Input Filter + Behaviour Guard]
        → [Layer 5: PHP INI Hardening]
        → PHP Execution

Each layer is independent. Disabling one does not affect the others.

Controls which PHP files can be executed via HTTP requests.

Turbine detects the entry point via structural heuristics (public/index.php or root index.php) and only allows that file:

[sandbox]
execution_mode = "framework"

• Apps with public/index.php — Only public/index.php is executable
• Apps with root index.php — Only index.php is executable

All other PHP files return 403 Forbidden, even if they exist. This prevents direct access to config files, helpers, or migration scripts via URL.

Explicitly whitelist which files can be executed:

[sandbox]
execution_mode = "strict"
execution_whitelist = [
    "public/index.php",
    "api/webhook.php",
    "cron/daily.php",
]

Blocks PHP execution inside directories that should only contain data:

[sandbox]
data_directories = ["storage/", "uploads/", "public/uploads/"]

Even if an attacker uploads a .php file to uploads/, it cannot be executed. This blocks common web shell attacks.

[sandbox]
blocked_upload_extensions = [".php", ".phtml", ".phar", ".php7", ".php8", ".inc", ".phps", ".pht", ".pgif"]
scan_upload_content = true

When scan_upload_content is enabled, Turbine inspects uploaded file content for PHP code signatures (<?php, <?=) regardless of the file extension.

Prevents path traversal attacks:

• Blocks ../ sequences
• Blocks null bytes (%00)
• Canonicalizes paths before execution
• Rejects double-encoded paths

No configuration needed — always active when security is enabled.

Layer 4 is a heuristic input filter implemented as Aho-Corasick automata compiled once at startup, plus a per-IP behaviour guard. Each request is scanned in a single O(n) pass regardless of the number of patterns. Results are cached by xxHash-64 so identical inputs pay ~50 ns on cache hit. The cache is bounded at 8 192 entries.

Coverage includes GET query strings, POST application/x-www-form-urlencoded bodies, and POST application/json bodies (first 8 KB scanned).

Both the SQL and code input filters are tiered by paranoia_level (0–3). Each level is cumulative — level 2 includes level 1 patterns, level 3 includes 1 + 2.

[security]
paranoia_level = 1              # default
exclude_paths  = ["/admin", "/api/docs"]

exclude_paths skips the input filter for requests whose path starts with any listed prefix. The behaviour guard, path guard, execution whitelist, and data-dir guard still run on excluded paths.

[security]
sql_guard = true

Patterns are case-insensitive, checked in a single Aho-Corasick pass:

When triggered:

• Returns HTTP 403 with a reason containing the matched substring.
• At paranoia_level >= 2, calls behaviour_guard.record_sqli_attempt(ip) — IP is temporarily blocked after sqli_block_threshold matches. At the default paranoia_level = 1 this coupling is intentionally off to avoid FP-driven bans.

[security]
code_injection_guard = true

Two-phase detection — obfuscation chains are checked first (high severity), then the paranoia-tiered patterns:

Obfuscation chains (always loaded when the guard is on):

Tiered patterns:

[security]
behaviour_guard              = true
max_requests_per_second      = 0     # 0 = disabled (opt-in)
rate_limit_window            = 60    # window in seconds
sqli_block_threshold         = 3     # temporary block after N heuristic SQLi matches

Per-IP profiles tracked in a lock-free DashMap with atomic counters. Three detection mechanisms:

The rate limit defaults to disabled (max_requests_per_second = 0) — the previous default of 100 r/s was too aggressive for normal traffic bursts. Set a value explicitly only if you want a hard per-IP cap.

Total blocked counter: GET /_/metrics exposes turbine_security_blocks_total.

Turbine configures PHP with secure defaults:

[sandbox]
disabled_functions = ["exec", "system", "passthru", "shell_exec", "proc_open", "popen", "pcntl_exec", "dl", "putenv"]
enforce_open_basedir = true
block_url_include = true
block_url_fopen = true

For development or benchmarking:

[security]
enabled = false

[sandbox]
enforce_open_basedir = false
block_url_include = false
block_url_fopen = false
disabled_functions = []

Warning: Never disable security in production.

All guards run in-process with Aho-Corasick automata compiled at startup. Pattern matching is O(n) in input length regardless of the number of patterns.

POST JSON body: first 8 KB scanned (cap avoids CPU waste on large uploads). Benchmark on a 100 KB JSON body showed no measurable difference vs a GET request — the 8 KB window costs ~4 µs vs the ~10 ms PHP execution floor.

This is negligible compared to PHP execution time (typically 1–50 ms).