Untrusted Data -- Injection & XSS

So far, we have checked who may read or change a note. Once we allow a request, we still need to decide how to use its data. What happens when a note title contains an apostrophe, or a profile biography contains HTML tags? Let’s follow those values through a database query, an API response and the browser.

Applications also use data in URLs, logs and configuration. A value safe in one context is not automatically safe in another. Injection occurs when untrusted data changes the meaning of a command or document instead of remaining data.

We will use notes and profiles to examine these boundaries through independent reading examples. The article and profile exercises supply their own files.

SQL values must not become SQL syntax

Start with a lookup by note title. For a notes table with id and title columns, let title be untrusted request text and sql a configured postgres.js client:

// Unsafe construction: do not execute this pattern.
const query = "SELECT id, title FROM notes WHERE title = '" + title + "'";

Concatenation makes title part of SQL syntax. The parameterized postgres.js version keeps it a value:

const rows = await sql`SELECT id, title FROM notes WHERE title = ${title}`;

Consider the title Reader's guide. In the concatenated query, its apostrophe becomes part of the SQL syntax. In the parameterized query, the complete title remains a value. Input validation does not replace parameterization.

Parameter placeholders cannot represent column names or sort keywords. For dynamic table or column names, select allowed identifiers and use the library’s identifier helper. For sort direction, choose ASC or DESC from an explicit allowlist. See the OWASP SQL Injection Prevention guidance.

Validate public response data

Our account examples have already selected the user fields that the browser may receive. Let’s apply that idea to a profile with a biography and an internal moderator note. Input validation checks a caller’s proposal. Output validation checks a value before the application returns it.

Output validation is especially useful when another application, an import job, a migration or an administrator can change stored data after our application has validated and saved it. An import might replace a valid biography with one longer than the public schema allows. Validation at the original write cannot guarantee that a later read still meets the response contract.

A changed repository query could also produce a string ID where a public response promises a number. Internal records may contain fields that must stay on the server.

After establishing that the caller may read the profile, we apply this public schema:

import { z } from "zod";

export const PublicProfileSchema = z.object({
  id: z.number().int().positive(),
  displayName: z.string().min(1).max(80),
  biography: z.string().max(500),
});

This schema omits unknown properties from the parsed result. It neither converts a string ID to a number nor repairs an invalid display name. Zod explains stripping, rejecting, and retaining unknown object keys.

When the record matches the schema, parse returns a new public value; otherwise, it throws. Return the parsed value and leave the original record unchanged. At the HTTP boundary, treat an invalid output as an internal error without exposing the record or schema diagnostics.

Use output validation at a public boundary; it need not be repeated in every layer. Access checks still matter: a schema-valid record can belong to someone else. OWASP discusses public property selection under object property authorization.

Before reading the comments below, predict which fields parsing will return. Will it also remove the HTML tags from the biography or accept a string ID?

const record = {
  id: 7,
  displayName: "Example user",
  biography: "<b>Just text</b>",
  moderatorNote: "private",
};

const publicProfile = PublicProfileSchema.parse(record);
// { id: 7, displayName: "Example user", biography: "<b>Just text</b>" }

record.moderatorNote; // "private": parsing did not modify the original.
PublicProfileSchema.safeParse({ ...record, id: "7" }).success; // false

The parsed result omits moderatorNote, keeps the biography’s tags as string content, and requires a numeric ID. The original record still has its internal field. The article exercise transfers this pattern to a different public schema.

Figure 1 follows the biography across two boundaries: the schema checks and selects public fields; rendering turns the string into text or markup. Passing the schema does not make a string safe for raw HTML.

Render user text as text

We now have a public biography, including any markup characters in its text. Let’s follow it into a Svelte component. Interpolations escape text:

<p>{biography}</p>

Raw HTML instead interprets the string as markup:

<!-- Do not use this for an untrusted biography. -->
{@html biography}

With <strong>not approved markup</strong>, interpolation displays literal characters while raw HTML creates an element. Untrusted raw HTML can also enable cross-site scripting (XSS): attacker-controlled code running in another user’s browser.

Compare the two outputs below. The first displays the tags as characters; the second uses them to make the words bold. This fixed HTML shows the difference:

<h2>Escaped text</h2>
<p>&lt;strong&gt;not approved markup&lt;/strong&gt;</p>
<h2>Rendered markup</h2>
<p><strong>not approved markup</strong></p>

The same behavior applies to a small notice component. Before reading the explanation below, consider whether its paragraph will contain a strong element:

<script lang="ts">
  const text = "<strong>Bring your notes</strong>";
</script>

<article>
  <h2>Room notice</h2>
  <p>{text}</p>
</article>

The paragraph has no strong child: the tags appear as text. This also holds when the string arrives through a prop or API.

Allow only HTTP and HTTPS profile links

For a profile that includes a website link, we need one more decision. HTML escaping does not restrict URL schemes, so a profile link also needs a scheme policy.

Parse a URL before rendering a link. The protocol property includes the scheme’s colon: new URL("https://example.test/help").protocol is "https:". Allow only "http:" and "https:"; omit links with other schemes, such as javascript:. A Zod URL schema can combine syntax checks with this protocol check.

Derive the parsed link from the current prop with Svelte’s $derived. Parsing only at component creation can leave a stale link after the prop changes. An invalid URL should remove the link; a later valid URL should restore it. The exercise supplies the URL schema.

Validation, authorization, and safe rendering

Returning to our notes workflow, checking who may read a record is only one part of handling it. A valid string can still be unsafe HTML, and a parameterized query can still return someone else’s private record. Validation, safe rendering and authorization need separate checks.

Next, we will return to the browser’s session cookie and examine requests that another page might trigger while the user is signed in.

Check Your Understanding

1. Why is validation not a substitute for parameterized SQL?
2. Why should an API return the parsed public output rather than the original record?
3. How does text interpolation differ from raw HTML insertion, even for a schema-valid biography?
4. Why does a profile URL need its own scheme policy, and what should happen when its prop changes to a disallowed URL?