Input-Validation and Data-Integrity Posture: A Proposed Axis for Whether AI App Builders Validate Untrusted Input at the Boundary (August 2026)

Every AI app builder will happily wire a form to a database. Type an email, click submit, watch the row appear. What almost none of them show you is what happens when the request does not arrive through that form: a script that posts a missing field, a number where a string was expected, a 200,000-character bio, or a value the UI would never have let a human enter. That is the question this axis proposes to measure. We are not scoring builders today. We are publishing a candidate axis, its rubric, its posture levels, and a reproduction protocol, and opening all of it for comment before it enters the composite.

Quick Answer

Input-validation and data-integrity posture is a proposed BuilderProof benchmark axis, drafted August 17, 2026, that scores whether the code an AI app builder emits validates untrusted input at the server boundary, or whether it trusts whatever the client sends. It is measured from the exported project: does the generated write endpoint reject a malformed request body with a 4xx, or does it coerce, crash, or silently persist it. The rubric weights six documentation-anchored signals, including server-side boundary validation, schema-based allowlist checks, rejection semantics, semantic and range checks, injection and over-posting resistance, and consistency across every write surface. The cohort under consideration is the five commercial builders we already track: v0, Lovable, Bolt, Replit, and Base44. This page is an axis proposal open for community edits, not a leaderboard.

Why we are proposing this axis

The canonical guidance here is old, settled, and unambiguous. OWASP states plainly that input validation "must be implemented on the server-side before any data is processed by an application's functions, as any JavaScript-based input validation performed on the client-side can be circumvented by an attacker who disables JavaScript or uses a web proxy." The OWASP Input Validation Cheat Sheet has said a version of this for years. The tooling caught up too: Zod, described on zod.dev as a TypeScript-first library to "define schemas you can use to validate data, from a simple string to a complex nested object," made schema validation at the boundary a one-liner in the exact Next.js stack these builders emit.

So the knowledge exists and the tools exist. The open question is whether AI app builders apply them in the code they generate. A model optimizing for a working preview has every incentive to make the happy path work and stop there, because the happy path is what the demo shows. Unvalidated input is invisible until someone sends the unhappy request. Searches for the input-validation quality of AI-generated apps return two disconnected bodies of writing: general best-practice articles about never trusting user data, and generic "best AI app builder" comparisons that score speed and looks. Nothing crosses them. No reproducible, tool-by-tool measurement of the validation posture of emitted code exists, and that is the gap this axis is built to close.

What "input-validation and data-integrity posture" means here

We scope the axis narrowly and deliberately. Posture is read from the untouched export, at the moment of generation, before a human hardens anything. Three boundaries keep it honest.

• It measures the server boundary, not the form. A polished client-side form with instant red error text scores nothing on its own, because the form is not the trust boundary. The endpoint behind it is.
• It is behavioral and static in equal parts. We read the emitted handler code, and we send a fixed battery of malformed requests to the running endpoint and record what comes back. Both halves are scripted, so both are reproducible.
• It is one axis, not a verdict. A builder can validate weakly and still score well on output quality or speed to first paint. The composite is where those trade off.

The proposed rubric

Six signals, each anchored to published guidance and each independently checkable. Weights are a starting point for community revision, not a settled formula.

The allowlist signal follows OWASP directly. The Cheat Sheet calls denylist filtering "a massively flawed approach as it is trivial for an attacker to bypass," and defines allowlist validation as "defining exactly what IS authorized, and by definition, everything else is not authorized." The semantic-checks signal uses OWASP's own split: syntactic validation "should enforce correct syntax of structured fields," while semantic validation "should enforce correctness of their values in the specific business context." We score both, because a field can be a syntactically valid string and still be a semantically impossible value.

The four posture levels

To make results legible at a glance, each builder's score maps to one of four levels.

• Level 0, client-trusting. Validation lives only in the UI, or nowhere. The server accepts whatever arrives and writes it.
• Level 1, partial boundary. Some server routes check some fields, inconsistently, often with manual if checks or denylist filtering rather than a schema.
• Level 2, schema at the boundary. Server write handlers validate with a schema, reject malformed input with a 4xx, and use parameterized database access.
• Level 3, parse-don't-validate by default. Every boundary parses untrusted input through a shared schema before any handler logic runs, typed and trusted data flows inward, and semantic checks, injection resistance, and over-posting protection are present without prompting.

The level names borrow the "parse, don't validate" discipline that the schema-validation ecosystem is built around: validate once at the edge, then trust the typed result everywhere downstream, exactly as Zod frames it.

How to reproduce it

The protocol is deliberately boring, which is the point. Reproducibility is the axis's reason to exist.

1. Generate a fixed reference app from the same prompt suite we use for every axis, one generation per builder, no manual edits. The reference prompt includes at least one create endpoint with typed fields, so every builder has a write surface to measure.
2. Export the project the builder allows you to export, and record the write-handler source verbatim.
3. Send a fixed adversarial payload battery to each write endpoint: a missing required field, a wrong-typed field, an empty string where a value is required, an out-of-range number, an oversize string, an unexpected extra field, and a string carrying SQL and HTML metacharacters.
4. Record the HTTP status and response body for each payload. A 400 or 422 with a structured error is a pass; a 200 that persists the row, a 500, or a silent coercion is a fail.
5. Statically classify the database access as parameterized or string-concatenated, and classify whether the handler mass-assigns the request body.
6. Publish the raw request-and-response log alongside the score, so the arithmetic is auditable.

Because the payload battery is fixed and the reads are from static source, two runs on the same export produce the same result. That property is what separates this from impression-based comparisons, and it is why the axis fits our reproducibility-first methodology.

The green-form illusion

The reason server-side validation carries the heaviest weight is that a working form is theater. The red "email is required" text a user sees is client-side, and the client is exactly the layer an attacker controls. Disable JavaScript, open a proxy, or just curl the endpoint, and every one of those UI guarantees evaporates. If the server behind the form does not re-check the same rules, the app is validated in appearance and unvalidated in fact.

This is the input-validation cousin of a pattern we have named on other axes: the green-typecheck illusion, where suppressed errors buy a passing compile, and the green-clock illusion, where a date looks right only because author and server share one timezone. Here the trap is that the demo works, the form rejects bad input in front of a human, and the endpoint accepts it from anyone who skips the form. An AI builder can make this worse than a careless human would, because the model sees a passing preview and has no incentive to write the invisible half. The number that matters is not whether the form validates. It is whether the endpoint does.

How this relates to our existing axes

Input-validation posture is adjacent to work we already publish, and we want to be explicit that it is not a duplicate.

It is not the type-safety posture axis. Type safety is a build-time property; the compiler checks shapes before the app runs. But TypeScript types are erased at runtime, so a green typecheck says nothing about whether a malformed JSON body is rejected when a real request arrives. Type safety guards the code against itself. Input validation guards the running code against the outside world. A project can be fully strict-typed and still write an untyped, unvalidated request body straight into the database.

It is not our auth and access-control work either. That axis asks whether the right person can reach an endpoint. This axis asks whether the right data can, once they are through the door. And it is upstream of injection risk in the OWASP Top 10, where A03:2021 Injection is the failure mode that unvalidated, unparameterized input feeds. Validation is not the only defense against injection, and OWASP is careful to say it "should not be used as the primary method," but a builder that validates at the boundary and parameterizes its queries has closed the most common door.

What we are not claiming yet

No scores today. This page proposes the axis, the rubric, the levels, and the method; it does not rank anyone. Publishing the rubric before the results is deliberate, so the cohort and the community can challenge the weights, the payload battery, and the reproduction steps before any builder is measured against them. BuilderProof benchmarks are community-editable by design, and axis proposals are the stage where that editing does the most good.

Limitations and open questions

• Single-generation variance. One export is one sample. A builder that is inconsistent between generations needs a multi-run design before scoring is fair.
• Prompt sensitivity. A prompt that explicitly asks for validation would measure instruction-following, not default posture. The reference prompt describes the app, not its defenses, on purpose.
• Weight subjectivity. The 25/20/15/15/15/10 split is a proposal. A strong argument that injection resistance should outweigh schema style would change the ranking, and we would rather have that argument now than after publishing scores.
• Export gaps. Signals that depend on reading handler source assume the builder lets you export it. A builder that hides its output cannot be fully scored here, and that itself is a finding rather than a null.

Comments, counter-rubrics, and reproduction attempts are welcome. If your run of the payload battery produces different results than ours will, that is the most useful thing you can send us.

BuilderProof Editorial Team. "Input-Validation and Data-Integrity Posture: A Proposed Axis for Whether AI App Builders Validate Untrusted Input at the Boundary (August 2026)". BuilderProof, August 2026. https://www.builderproof.org/benchmarks/input-validation-data-integrity-posture-axis-proposal-august-2026.

@misc{builderproof-input-validation-data-integrity-posture-axis-proposal-august-2026,
  title  = {{Input-Validation and Data-Integrity Posture: A Proposed Axis for Whether AI App Builders Validate Untrusted Input at the Boundary (August 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {aug},
  howpublished = {\url{https://www.builderproof.org/benchmarks/input-validation-data-integrity-posture-axis-proposal-august-2026}},
  note   = {BuilderProof, builderproof.org}
}