Secure protocol parsing

Check message size, structure, types and meaning before processing the contents. Apply the same limits to network data, SDK callbacks and saved captures.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.

Verification and testing

Overview#

Every device message, event, discovery response, media descriptor, serial frame, XML document, JSON body, topic name, SDK callback, and stored capture is untrusted input. Parse bytes into a validated model before any state transition or actuation decision.

Parsing pipeline#

1. Bound transport reads by maximum frame/document size and deadline.
2. Distinguish clean end of stream, timeout, truncation, protocol error, and resource exhaustion.
3. Validate framing length, checksum or integrity field before allocating from attacker controlled sizes.
4. Decode with an explicit character set, byte order, numeric width, and overflow policy.
5. Reject unknown critical versions/types; preserve unknown optional fields only when the specification permits it.
6. Canonicalize once, then validate schema, ranges, identifiers, counts, nesting, and cross field invariants.
7. Apply replay, sequence, timestamp, session, authorisation, and state transition checks.
8. Convert to an internal typed representation that can't express impossible combinations.
9. Log a bounded, redacted diagnostic; never echo arbitrary binary or sensitive values blindly.

Binary protocols#

• Check minimum header length before field access.
• Perform overflow safe arithmetic before computing end offsets or allocation sizes.
• Treat declared length as a claim, not a fact; compare it with the received buffer and protocol maximum.
• Decode fixed width integers explicitly and avoid alignment dependent casts.
• Validate CRC/checksum where defined, but don't treat error detection as authentication.
• Bound loops over objects, registers, TLVs, APDUs, topics, channels, or media tracks.
• Keep parser state separate per peer/session and reset it predictably after malformed input.

XML and structured text#

Disable external entity resolution and network/file retrieval unless a narrowly reviewed specification truly requires them. Bound document size, nesting, attributes, namespaces, expansion, and collection counts. Validate the post parse semantic model; a well formed SOAP or JSON document can still request an unauthorised or impossible operation.

State machines#

Reject messages that are valid in isolation but invalid for the negotiated version, direction, role, authentication state, or sequence. Specify behaviour for duplicates, retries, out of order delivery, unknown extensions, reconnect, resumption, peer reboot, and partial writes.

Language emphasis#

Defensive verification design#

Validate parsers with synthetic fixtures covering empty, minimum, maximum, truncated, overlong, wrong version, bad integrity, duplicate, replayed, out of order, unknown field, invalid encoding, and state invalid cases. Keep fuzzing inside an isolated offline parser harness or an explicitly owned loopback process; never direct it at operational devices.

Sources#

• NIST SSDF, NIST SP 800-218 Version 1.1, secure development practices, accessed 25 August 2026.
• CWE 20, CWE 20: Improper Input Validation, MITRE weakness definition and mitigations, accessed 25 August 2026.
• CWE 611, CWE 611: Improper Restriction of XML External Entity Reference, accessed 25 August 2026.

Related pages#

• API and event security
• Development and integration
• Defensive labs