Skip to content

Section 25: Input Validation and Trust Boundaries

TECHSPEC-26 — Section 25 · Version 0.1 · Status: Initial Draft

Numbering note: this is file TECHSPEC-26.md but it contains Section 25 of the specification. File numbers and section numbers diverge from TECHSPEC-23 onward; neither has been renumbered. See the specification index and audit AUDIT-001 in reports/documentation-audit.md for details.

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Security Philosophy

All data entering a program from outside its trusted internal state must be treated as untrusted until it has been validated.

The language must make trust boundaries explicit and prevent unvalidated external data from being silently treated as trusted application data.

Validation must establish specific properties. It must not imply that data is safe for every possible use.

2. Untrusted Data Sources

The following sources are considered untrusted by default:

  • User input.
  • HTTP requests and responses.
  • Files read from external locations.
  • Database records from untrusted or uncontrolled sources.
  • Third-party APIs.
  • Environment variables.
  • Command-line arguments.
  • External process output.
  • Deserialized data.
  • Data received through network connections.

A value's origin and trust status must not be silently discarded.

3. Untrusted Types

The language must provide a way to represent data that has crossed a trust boundary but has not yet been validated.

Proposed type:

UNTRUSTED<String>

Example:

LET rawInput: UNTRUSTED<String> =
    READ_USER_INPUT()

Rules: - External input must enter through an explicitly declared boundary. - Untrusted values cannot automatically become trusted application values. - Validation must identify the properties it establishes. - Validation of one property must not imply unrelated properties. - A value must retain its untrusted status until the required validation succeeds.

4. Validation Contracts

Validation functions must declare exactly what they establish.

Example:

FUNCTION validateEmail(
    input: UNTRUSTED<String>
) -> Result<EmailAddress, ValidationError>

    ENSURES: SUCCESS result contains a syntactically valid EmailAddress
    EFFECTS: NONE
    FAILURES: InvalidEmail

END FUNCTION

Rules: - Validation must have an explicit success or failure result. - Successful validation establishes only the guarantees declared by the function. - Validation must not silently modify input unless mutation is explicitly declared. - Validation must preserve the relationship between the checked value and the value subsequently used. - Validation rules must be testable and documented.

5. Constrained Types

Validated values should use types that represent their established constraints.

Example:

TYPE PositiveAmount =
    Decimal WHERE VALUE > 0

A value cannot be assigned to PositiveAmount unless the required constraint has been established.

Rules: - Constraints must be explicit. - Constraint violations must produce a defined failure. - The compiler must enforce constraints statically when possible. - Runtime checks must be used when static verification is insufficient. - A successful check must not be treated as permanent if the underlying value can change.

6. Context-Specific Safety

Validation for one context does not automatically establish safety in another.

For example: - Valid HTML text is not necessarily safe JavaScript. - Valid SQL data is not necessarily safe to concatenate into a query. - A valid URL is not necessarily an authorized destination. - A valid file path is not necessarily permitted to access. - A valid username is not necessarily an authenticated identity.

The standard library must provide context-specific APIs for operations such as: - HTML escaping. - SQL parameterization. - URL validation. - File path validation. - Structured serialization. - Command argument handling.

The language must discourage unsafe string concatenation for security-sensitive operations.

7. Trust Boundaries

Programs must declare boundaries where data enters or leaves trusted execution.

Examples include: - Network interfaces. - Database interfaces. - Filesystem interfaces. - Process execution. - User-facing APIs. - External service integrations.

Rules: - Boundary operations must declare their effects and permissions. - Data crossing a boundary must have an identifiable source. - Data leaving the program must satisfy the destination's declared requirements. - Authentication and authorization must remain separate from input validation. - Trust must not be inherited merely because data came from an authenticated source.

8. Validation and Mutation

Validation must apply to the exact value that is subsequently used.

Rules: - Changing a value after validation may invalidate the validation result. - Mutable data must be revalidated when relevant constraints may have changed. - Immutable validated values may retain their established guarantees. - Validation must not create a false guarantee about a different copy or reference. - The compiler must track relevant changes where possible.

9. Compiler and Runtime Responsibilities

The compiler and runtime must: - Identify untrusted values. - Enforce declared validation requirements. - Prevent unauthorized conversion from untrusted to trusted types. - Track established constraints. - Detect invalidated validation guarantees where possible. - Enforce trust-boundary permissions. - Report missing or insufficient validation. - Preserve validation semantics during code generation.

10. Verification Limitations

The language must not claim that validated input is universally safe.

Validation establishes specific properties under specific assumptions.

The compiler must distinguish: - Validation declared. - Validation statically established. - Validation executed successfully. - Validation not established. - Validation failed.

A successful validation function does not prove that the entire application is secure.

11. Design Goal

An AI agent must be able to identify where external data enters a program, what is known about that data, what validation has occurred, and which guarantees remain unestablished.

Trust must be earned through explicit validation, not assumed from a value's origin.

Source file: TECHSPEC-26.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.