Safeguard
Application Security•

ASVS 5.0 V1.5.3: Keep Parsers Consistent for the Same Data

ASVS 5.0 V1.5.3 (Level 3) requires every parser of one data type to behave the same, with one character encoding. Avoid JSON and URL parser mismatches.

Safeguard Security Team
3 min read

ASVS 5.0 V1.5.3 requires that when different parsers handle the same type of data in your application, such as JSON, XML or URLs, they parse it consistently and use the same character encoding. It is a Level 3 requirement, aimed at high assurance systems.

Why it matters

Attacks appear in the gap between two parsers. A gateway checks a request with one JSON library and the backend reads it with another. If they disagree, the check passes something the backend interprets differently. Examples are duplicate keys, where one parser keeps the first and another the last, and URLs where a validator and an HTTP client disagree about the host. That second case is a classic way to get around an SSRF allowlist.

How to implement it

Parse once, at the edge, into a typed structure, and pass that structure on instead of the raw text. Never validate on one representation and use another.

Reject ambiguity. For JSON, refuse duplicate keys:

import json

def reject_duplicates(pairs):
    out = {}
    for key, value in pairs:
        if key in out:
            raise ValueError("duplicate key: " + key)
        out[key] = value
    return out

data = json.loads(body, object_pairs_hook=reject_duplicates)

Decode input as UTF-8 only, and reject invalid byte sequences instead of replacing them. For URLs, parse with the same library that makes the request, then check the parsed host, not the raw string. Where two services must parse the same input, list the libraries and versions in your documentation and cover the edge cases with shared test vectors.

How to test it

Build a corpus of tricky inputs: duplicate keys, mixed case keys, comments in JSON, a URL with credentials and an at sign, backslashes, encoded dots, and overlong UTF-8. Run it through every component that touches the data and compare the results. Any difference is a finding.

Cases worth putting in your test corpus

Duplicate keys are the best known JSON problem, and there are others: different handling of very large numbers, of comments and trailing commas, of invalid Unicode escapes, and of the key order. For URLs, compare how libraries treat a backslash, a username before an at sign, an encoded dot or slash, a missing scheme, and a fragment. For files and paths, compare handling of dot segments, null bytes and encoded separators.

Run each case through every parser in the chain and record the result in a table. Where two libraries disagree, either pick one library for the whole system or normalize the input once at the edge. Pin parser versions in your lockfile, because a dependency update can change behaviour.

Common mistakes

  • Validating with a regex on raw text and parsing later.
  • Different default encodings across services or languages.
  • Assuming two libraries for the same format agree because both claim to follow the RFC.

Quick check

Why does a duplicate key matter?

A gateway may read the first value and the backend the last. The attacker puts a harmless value first and a privileged one last.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.