How does Concise Binary Object Representation (CBOR) work?

How CBOR encodes structured data

CBOR is not a text syntax like JSON. It encodes data as compact binary items, with each item carrying its own type and length information. That makes it efficient for machines to parse because the decoder does not need to infer structure from delimiters or escape rules. The format can represent numbers, strings, arrays, maps, booleans, null, and binary blobs in a way that is small and predictable.

At a practical level, the encoder writes a major type and additional information into the first byte, then follows with any extra bytes needed for the value. Small integers can fit directly into the initial byte, while larger values, longer strings, or nested containers use extra length fields. That design is what gives CBOR its space savings and fast decode path.

CBOR also supports tagged values and deterministic encodings for use cases that need consistent serialization. Tags let applications attach semantic meaning to a value, such as a timestamp or a big integer, without changing the core binary structure. Deterministic encoding matters when systems must compare or sign serialized data reliably.

Why CBOR is used in constrained and machine-to-machine systems

CBOR is chosen when size, speed, and parser simplicity matter more than human readability. It is common in embedded systems, IoT, telemetry, mobile protocols, and other environments where every byte counts. Because it avoids the overhead of textual formats, it can reduce bandwidth, storage, and CPU cost during serialization and parsing.

That efficiency does not come for free. The receiver must know how to interpret the schema or agreed data model, because binary formats are less self-describing than text formats. If producers and consumers diverge on field meaning, length handling, or type expectations, interoperability problems appear quickly and may be harder to diagnose than with a plain-text payload.

CBOR is also useful when a protocol needs to carry both structured fields and raw bytes without base64 overhead. In many implementations, that makes it a better fit than JSON for compact authenticated messages, device commands, or constrained API payloads. The trade-off is that engineers must be more disciplined about versioning, validation, and canonical handling across implementations.

What to watch for when parsing CBOR safely

CBOR’s binary nature shifts the main risk from human readability to parser trust. A decoder that accepts malformed lengths, unexpected tags, deeply nested containers, or oversized byte strings can be driven into crashes, memory pressure, or logic errors. The format is compact, but compactness does not make malformed input safe.

Because CBOR is often used in protocol boundaries, it should be treated as untrusted input even when it originates from a partner device or internal service. Type confusion is a recurring failure mode: a value that is technically valid CBOR may still be invalid for the application’s expected schema. When the application assumes a string but receives an array, or assumes a short integer but receives a very large value, the unsafe path is usually in the implementation, not the format itself.

Failure mechanism: Poorly bounded decoders, inconsistent schema enforcement, and permissive tag handling can allow malformed CBOR to reach parser internals, trigger resource exhaustion, or exploit edge cases in libraries.

Impact: The practical effect can range from denial of service to application logic corruption, and in some cases memory-safety or deserialization flaws in the consuming component.

Practitioner Guidance

What to verify: Confirm that every CBOR consumer enforces expected types, maximum nesting depth, maximum item length, and total message size before deep parsing. Validation should happen as early as possible, especially on interfaces exposed to external parties or lower-trust devices.

Common mistake: Do not assume that “binary” means “safer” or that a library’s default decoder settings are sufficient. The right test is whether the implementation rejects unexpected structure cleanly and fails closed when length, type, or depth limits are exceeded.

Practitioner takeaway: Treat CBOR as an efficient transport encoding, not as a security control; the security outcome depends on strict schema enforcement, bounded parsing, and defensive handling of all untrusted payloads.

Related resources from NHI Mgmt Group

• Concise Binary Object Representation (CBOR)
• How does Binary Large Object work?
• How does Binary Ninja work?
• How does Decoy Object work?