Keep data separate from instructions

A customer writes an apostrophe in their name. A secure application should store it correctly and display it correctly. Deleting punctuation is not a good definition of security.

Parameterization: Keeping a query structure separate from the data values supplied to it.

Validation asks whether data belongs

Validation checks expected structure, length, range, and business meaning. A quantity can be an integer yet still be invalid because it is negative. The server performs its own checks even if the browser helped the user fill in a form.

Validation is not a universal cleaning function. Names, addresses, and messages can legitimately contain punctuation and non-English characters. A rule that destroys valid data may frustrate users while leaving the important interpreter boundary unprotected.

A database needs structure and values apart

Parameterized queries keep supplied values separate from the query’s intended structure. They are a different control from HTML encoding. Some query elements, such as a choice of sortable column, are not ordinary value parameters; map those choices to an explicit set of permitted identifiers.

Database accounts should also have only the access the application needs. This limits consequences if another control fails, but does not repair unsafe query construction.

Output belongs to a context

A browser interprets HTML text, attributes, URLs, and scripts differently. Use framework-supported safe rendering and encoding appropriate to the destination. If the application intentionally permits rich HTML, it needs suitable sanitization rather than ordinary text escaping alone.

Encoding too early can cause double encoding or corrupt data. Prefer storing the intended value and applying the appropriate control when passing it to an interpreter. Content Security Policy can reduce some consequences, but should supplement sound rendering rather than excuse unsafe insertion.

Worked review: the same value, a new destination

A fictional bookshop accepts plain-text reviews. The server’s policy permits ordinary punctuation and international names within a documented length limit. The exercise supplies the validation result; you do not need to count characters or construct a query.

• V1: A short ordinary review mentions author O’Neil. The server reports that its length and business-field requirements pass. The intended stored review retains that apostrophe.
• V2: The design review confirms a fixed query with the review supplied through the database’s value-binding mechanism. Sort choices “newest” and “helpful” map to two approved structural choices. The database account has only the service’s required access.
• V3: The customer page renders the stored review as HTML text through the framework’s escaping facility. A supplied output record confirms the intended text is displayed.
• V4: A proposed staff preview would insert the same stored value as trusted HTML. No rich-content policy or sanitization evidence accompanies that proposal. The feature has not been approved.

PredictDoes V2’s correct parameterization make V4 ready to ship because the value has already passed through a secure database boundary?

No. V2 controls how the database interprets a value. V4 introduces a browser interpretation that V2 does not govern. Either retain plain-text rendering or define and verify an appropriate rich-content policy before approving that feature. No harmful payload is needed to identify this design gap.

Preserve data while reviewing interpreters

V1 is a useful business check. It does not label the stored text universally safe. A quantity, a review body and a selectable sort option can each require different validation because their intended meanings differ.

V2 deliberately separates ordinary values from structural choices. Many database interfaces cannot bind a table or column identifier as a normal value. An approved mapping constrains those choices while actual review text remains bound data. Authorization still determines which records a caller may access; parameterization does not supply that decision.

V3 demonstrates the intended text-display behavior for the supplied record. Avoid storing a universal “HTML-safe” version merely because one destination is HTML: a future destination may use different interpretation rules, and repeated encoding can corrupt the visible value.

V4 therefore needs its own acceptance decision. If rich formatting is unnecessary, text rendering keeps the intended feature simpler. If it is required, define the allowed content and verify suitable sanitization and destination handling; do not assume a formatting preview inherits safety from storage.

Model deliverable: preserve the legitimate apostrophe, keep the fixed query and bounded sort mapping, and block approval of the undocumented rich preview until its separate requirement is met. Report design evidence and observed output separately from untested behavior.

EXPLORE THE CONCEPT

Choose the boundary

A fictional customer name is used in three places. Which control belongs there?

A form accepts the name

Validate reasonable length and business requirements without assuming punctuation is malicious.

The name becomes a query value

Pass it through the database’s parameter mechanism, keeping query structure fixed.

The name appears on a page

Render it as text with the appropriate output handling for that HTML context.

A simplified learning model. It connects to no systems and uses no real data.

Turn the idea into a decision

Ask “what will interpret this value next?” The answer tells you which boundary control to use. Validation, query parameters, output encoding, and least privilege have different jobs.