Privacy filter bypasses through JSON object keys, embedded encodings, and compression expansion

## When this applies

Use this when implementing or reviewing a privacy filter that inspects outgoing JSON or structured documents for filesystem identifiers, account names, or other private strings. This applies whether you are building the filter from scratch, adding validation to an existing system, or investigating why sensitive data passed through an existing filter.

## The bypasses it prevents

Three critical bypass channels let identifying data evade filters that only validate string values:

**Object key bypass.** JSON object keys are strings. If validation only examines property values, an attacker places the sensitive data in a key instead. The filter reads the property value and approves it. The receiver processes both keys and values and extracts the identifying string from the key name.

**Embedded format bypass.** A string value can contain encoded or nested structured data. After JSON parsing, a field holding stringified JSON or base64-encoded content is an opaque string. The validator sees the outer structure only. The receiver decodes the inner layer and reconstructs the identifying string. Recursively decoding every string creates new resource exhaustion vectors.

**Compression expansion bypass.** If byte limits check compressed request size before decompression, a small gzipped payload expands to exhaust memory or exceed limits during parse. A one megabyte compressed document can decompress to one hundred megabytes. The byte limit must apply after decompression, or compression becomes a resource exhaustion channel.

## Implementation precision requirements

**Validate both keys and values.** Walk the parsed object tree and inspect every string, whether it appears as a property value or a property name. Object key enumeration must feed the same validation rules as value inspection.

**Define an embedded format policy.** Either accept the leakage channel and document it, or recursively decode with strict depth and iteration limits. Recursive decoding requires separate fuel budgets per encoding type to prevent an attacker from chaining encodings to exhaust resources.

**Measure work budget as CPU time.** Wall time is vulnerable to CPU throttling and system load attacks. Operation counts require defining what counts as one operation, and different parsers have different costs. CPU time with a fallback to operation count when OS support is unavailable gives the most reliable bound. The budget must be shared across all phases: decompression, parsing, validation, and any re-encoding.

**Apply size limits post-decompression.** Check the content-encoding header. If compression is present, enforce the byte limit after decompression completes, not on the compressed wire size. Alternatively, reject compressed requests entirely if decompression is not needed.

**Verify unicode normalization.** The JSON parser must normalize unicode escape sequences to their character representations before validation runs. For example, a backslash followed by u and four hex digits representing a separator must become the separator character itself. Test with alternate representations to confirm the parser and validator agree on what string they are examining.

**Handle null bytes correctly.** JSON allows unicode escape sequences representing null bytes in strings. Some validators in C-like languages treat null as a terminator and stop reading while the receiver continues. Explicitly reject embedded null bytes or verify the validation library reads past them.

## Validation and logging architecture

After addressing the bypass channels, the core architecture remains:

1. Parse the JSON to its object tree representation
2. Walk both keys and values, validating each string against identifying patterns
3. Reject the entire document when any limit exhausts: byte, depth, work budget, or regex steps
4. Log only metadata: which field, which rule, timestamp, a cryptographic hash of the rejected document
5. Never echo the rejected content in logs, error responses, or partial results

## Testing approach

This guidance is based on reasoned analysis of bypass channels and implementation failure modes, not executed tests against a specific implementation. To verify a filter:

- Test with identifying strings in object keys, not just values
- Test with nested JSON-as-string and base64-encoded identifying content
- Test with compressed payloads that expand past limits
- Test with unicode-escaped separators and null byte sequences
- Verify logs contain no actual strings, only field identifiers and rule codes

Use obviously synthetic placeholder values in tests so no real identifying data appears in test artifacts or CI logs.

## Related considerations

Allowlisting acceptable formats inverts the problem and eliminates many bypass risks. If only UUIDs or specific controlled prefixes are valid, identifying strings in unexpected formats fail without needing to detect them.

Field names can leak identifiers when the field name itself contains user-specific data. This is less severe than value leakage but may still violate privacy requirements depending on the system.

Error responses to clients should be opaque, revealing neither field names nor rule details, to prevent structure disclosure.