// Sanitize user-generated content for display
entity Comment {
    author: text
    body: text
    sanitized_body: text
}

fn create_comment(author: text, raw_body: text) { Comment.create( author: author, body: raw_body, // Store original sanitized_body: sanitize_html(raw_body) // Store sanitized ) } ```

SQL Injection Prevention

FLIN's entity system uses parameterized queries internally, which prevents SQL injection by design. But for developers who construct raw queries (escape hatch for advanced use cases), sanitization functions are available:

// Escape a string for safe SQL inclusion
safe = escape_sql("Robert'; DROP TABLE users; --")
// "Robert''; DROP TABLE users; --"

// Escape for LIKE patterns safe_pattern = escape_sql_like("100%") // "100\%" ```

escape_sql doubles single quotes, which prevents the classic SQL injection attack. escape_sql_like also escapes % and _ wildcards, preventing pattern injection in LIKE queries.

In practice, FLIN developers should almost never need these functions. The entity system's query API is parameterized:

// Safe by default -- parameterized query
user = User.find_by(email: user_input)

// Also safe -- where clause is parameterized users = User.where(name: search_term) ```

URL Sanitization

// Encode for URL parameters
url_encode("hello world & more")
// "hello%20world%20%26%20more"

// Decode URL parameters url_decode("hello%20world") // "hello world"

// Build a safe URL base = "https://api.example.com/search" query = url_encode(user_input) safe_url = "{base}?q={query}" ```

URL encoding ensures that special characters in user input do not break URL structure or get interpreted as URL components.

Path Traversal Prevention

// Sanitize a file path
safe_path = sanitize_path("../../etc/passwd")
// "etc/passwd" (relative traversal removed)

// Validate that a path is within a base directory is_safe = path_within("/uploads", user_provided_path) ```

sanitize_path removes .. components and leading slashes, preventing directory traversal attacks. path_within checks that a resolved path stays within a specified base directory.

Entity-Level Validation

FLIN's entity system integrates validation at the schema level using where constraints:

entity Product {
    name: text where len >= 1 and len <= 200
    description: text where len <= 5000
    price: float where > 0
    sku: text where matches("^[A-Z]{2}-\\d{4}$")
    email: text where is_email
    url: text? where is_url
    category: text where in ["electronics", "clothing", "food", "other"]
}

These constraints are checked automatically on create and update operations. If any constraint fails, the operation returns an error with a descriptive message. The developer does not need to write validation logic separately -- it is declared once in the entity definition and enforced everywhere.

// This fails validation automatically
result = Product.create(
    name: "",                    // Too short
    price: -5.0,                 // Not positive
    sku: "invalid",              // Does not match pattern
    email: "not-an-email"        // Not a valid email
)
// Errors:
// - "name: length must be >= 1"
// - "price: must be > 0"
// - "sku: must match pattern ^[A-Z]{2}-\d{4}$"
// - "email: must be a valid email address"

Composing Validation and Sanitization

Real-world input handling combines validation and sanitization in sequence:

fn process_user_input(raw_name: text, raw_email: text, raw_bio: text) {
    // Step 1: Sanitize (make safe)
    name = raw_name.trim
    email = raw_email.trim.lower
    bio = sanitize_html(raw_bio)

// Step 2: Validate (check acceptability) errors = []

{if name.is_empty} errors.push("Name is required") {else if name.len > 100} errors.push("Name must be 100 characters or less") {/if}

{if not email.is_email} errors.push("A valid email address is required") {/if}

{if bio.len > 5000} errors.push("Bio must be 5000 characters or less") {/if}

{if errors.len > 0} return { success: false, errors: errors } {/if}

// Step 3: Persist (store validated, sanitized data) user = User.create(name: name, email: email, bio: bio) return { success: true, user: user } } ```

The pattern is always the same: sanitize first (trim, normalize, remove dangerous content), validate second (check format and constraints), persist third (store the clean data). FLIN's built-in functions make each step a single line.

Implementation: Compiled Rust Validators

Each validation function is implemented as a Rust function that operates directly on the string's bytes. No regular expressions are used for standard validations (email, URL, IP address). Instead, each validator is a hand-written state machine that is both faster and more correct than a regex.

fn is_valid_email(s: &str) -> bool {
    // Simplified RFC 5322 validation
    let at_pos = match s.find('@') {
        Some(pos) if pos > 0 => pos,
        _ => return false,
    };

let local = &s[..at_pos]; let domain = &s[at_pos + 1..];

// Local part validation if local.is_empty() || local.len() > 64 { return false; }

// Domain validation if domain.is_empty() || domain.len() > 253 { return false; }

// Domain must contain a dot if !domain.contains('.') { return false; }

// TLD must be at least 2 characters let tld = domain.rsplit('.').next().unwrap(); if tld.len() < 2 { return false; }

true } ```

This email validator is not a complete RFC 5322 implementation (which would allow quoted strings, comments, and other rarely-used features). It is a practical validator that accepts every email address a real user would have and rejects obvious non-emails. This pragmatic approach matches what every production email validator does -- including the ones in validator.js, django.core.validators, and govalidator.

The HTML sanitizer uses a streaming parser that processes the input character by character, maintaining a stack of open tags and a whitelist of allowed tags and attributes. It never builds a DOM tree in memory, so it handles arbitrarily large inputs without memory pressure.

What We Validate vs. What We Sanitize

The distinction between validation and sanitization is often confused. Here is FLIN's clear separation:

Validation functions answer the question "is this input acceptable?" They return booleans and do not modify the input:

• is_email, is_url, is_ip, is_uuid
• is_numeric, is_alpha, is_alphanumeric
• is_phone, is_credit_card, is_hex_color
• len_between, between, matches

Sanitization functions answer the question "how do I make this input safe?" They return modified strings:

• html_escape, strip_tags, sanitize_html
• escape_sql, escape_sql_like
• url_encode, url_decode
• sanitize_path
• trim, lower, upper (normalization)

Using both together is the correct pattern: sanitize input before storage, validate input before processing, sanitize output before display. FLIN makes all three steps trivial.

Sixty-Seven Functions, Zero Vulnerabilities

The complete validation and sanitization API:

• 15 format validators (email, URL, IP, UUID, phone, credit card, etc.)
• 5 content validators (numeric, alpha, alphanumeric, empty, blank)
• 6 length/range validators (len_between, len_min, len_max, between, etc.)
• 1 pattern validator (matches)
• 3 HTML sanitizers (html_escape, strip_tags, sanitize_html)
• 1 HTML unescaper (html_unescape)
• 2 SQL sanitizers (escape_sql, escape_sql_like)
• 2 URL encoders (url_encode, url_decode)
• 2 path sanitizers (sanitize_path, path_within)
• 2 base64 coders (base64_encode, base64_decode)
• 28 entity constraint keywords (where, in, between, matches, etc.)

Sixty-seven functions that replace validator, sanitize-html, xss, dompurify, express-validator, and a dozen other security-related packages. All built-in. All handling edge cases correctly. All making the secure path the default path.

---

This is Part 79 of the "How We Built FLIN" series, documenting how a CEO in Abidjan and an AI CTO built input validation and sanitization directly into a programming language.

Series Navigation: - [78] Reduce, Map, Filter: Higher-Order Functions - [79] Validation and Sanitization Functions (you are here) - [80] Error Tracking and Performance Monitoring - [81] FlinUI: Zero-Import Component System