What mitigations reduce the risk of failure to sanitise paired delimiters?

Why paired delimiters need explicit sanitisation

Paired delimiters are structural characters, so the risk is not limited to visible escaping. A sanitizer that handles only one side of the pair can leave an input syntactically valid but semantically different after parsing. That is how quotes, brackets, and parentheses become control characters for a downstream parser, template engine, or interpreter.

The practical question is whether the input still means the same thing after normalisation. Balanced pairs preserve structure; partial sanitisation can shift where a token ends, expose hidden content, or let attacker-controlled text escape its intended container.

That is why paired-delimiter handling belongs in the same family as CWE Top 25 Guide guidance on common weakness patterns, especially delimiter neutralisation and parsing mistakes that change program flow.

How to prevent delimiter imbalance after normalisation

Sanitise both characters in the pair, then verify the result after any canonicalisation step. If input is normalised first, the sanitizer has to run on the post-normalised form, not the raw string, because encoding changes can reveal or create delimiter characters that were not obvious earlier.

Use a syntax-aware parser where possible. Parsers understand nesting, quoting contexts, and token boundaries, while regular-expression shortcuts often miss edge cases such as escaped quotes, nested brackets, or mixed encodings. The safer pattern is to parse according to the grammar, validate the resulting structure, and reject inputs that cannot be made structurally consistent.

Balance checks should cover truncation and nesting depth as well as simple open-versus-close counts. If one character of the pair is dropped, duplicated, or moved by a transformation step, the sanitizer has not preserved the original structure. That failure is especially dangerous when the delimiter controls a list, expression, JSON-like object, or command argument boundary.

What to test when delimiter sanitisation is incomplete

Test cases should include nested delimiters, deliberately unbalanced input, escaped delimiters, mixed encodings, and inputs that become shorter or longer after canonicalisation. Those cases are where a control that looks correct in ordinary input often fails, because the parser sees a different token stream than the reviewer expected.

Also test for context switching. A character that is harmless in one field can become structural in another, so the same sanitiser may be insufficient if the input later passes through SQL, HTML, JSON, a shell, or a templating layer. The failure mode is often a boundary mismatch, not a classic injection payload.

For broader parser and input-validation patterns, the OWASP API Security Top 10 is a useful reference when delimiter handling affects object boundaries, request structure, or function dispatch. Where the weakness sits in a software delivery process, the OWASP SAMM model helps teams make validation and secure coding repeatable rather than ad hoc.

Risk and Threat Considerations

Failure to sanitise paired delimiters can turn a simple input defect into a structure-breaking issue. An attacker does not need to inject a long payload if they can alter how the application groups data, ends a string, or closes a container. That can create injection, logic corruption, or unexpected parser behaviour even when the visible input looks small.

Failure mechanism: One side of a paired delimiter is preserved while the other is removed, escaped, normalised, or reinterpreted, leaving the downstream parser with unbalanced syntax.

Impact: The application may misparse user input, change control flow, corrupt data structures, or pass attacker-controlled content into a more privileged interpreter or sink.

Practitioner Guidance

What to verify: Confirm that sanitisation is applied after canonicalisation and before any component that interprets structure. The control is only trustworthy if the final parsed form, not just the raw input, remains balanced and context-safe.

Common mistake: Treating delimiter escaping as a string-replacement problem. That approach often fails when the input is nested, encoded, or reused across multiple contexts, because the original grammar rules are still in play.

What good looks like: The team uses grammar-aware validation for structured input, has explicit tests for imbalance and escaping, and rejects any value that cannot be parsed into a well-formed structure without ambiguity.

Practitioner takeaway: If a delimiter can change meaning after parsing, sanitise the full pair and validate the final structure, not just the visible characters.

Related resources from NHI Mgmt Group

• What causes failure to sanitise paired delimiters?
• How do developers prevent failure to sanitise paired delimiters?
• What mitigations reduce the risk of failure to disable reserved bits?
• What mitigations reduce the risk of improper neutralisation of delimiters?