System.Text.Json is the default JSON serializer in modern .NET applications. It converts objects to and from JSON with strong performance and deep framework integration, but its default behavior can expose unintended data if developers do not define explicit serialization boundaries and exclusion rules for sensitive fields.
Expanded Definition
System.Text.Json is the built-in JSON serialization stack for modern .NET, designed for speed, low allocation overhead, and tight integration with the platform’s type system. In security-sensitive applications, it is not just a formatting utility; it is a data boundary mechanism that determines which object members leave process memory, how incoming JSON is interpreted, and whether sensitive values are excluded by default or exposed by mistake. Its behaviour is shaped by attributes, naming policies, custom converters, ignore rules, and source-generated metadata, so the effective output can differ significantly from a class’s full in-memory structure. That makes it especially relevant where APIs, configuration objects, and identity-adjacent payloads contain secrets, tokens, claims, or personal data. Microsoft’s documentation for JSON serialization and the NIST Cybersecurity Framework 2.0 both reinforce the need to treat data handling as a governed control surface rather than an implementation detail. The most common misapplication is assuming that default serialization is safe for all objects, which occurs when developers expose domain models directly to API responses without explicit exclusion rules.
Examples and Use Cases
Implementing System.Text.Json rigorously often introduces configuration overhead, requiring organisations to weigh developer convenience against tighter control over what data is serialised, logged, or accepted from untrusted input.
- API response shaping, where only approved properties are emitted and fields such as passwords, access tokens, or internal flags are suppressed before the payload reaches clients.
- Deserialising partner or user-supplied JSON with strict property expectations, so unexpected fields do not silently alter application state or populate unsafe objects.
- Identity and access workflows, where claims-like structures, tenant metadata, or account attributes must be serialised in a bounded way to avoid leaking unnecessary personal data.
- Configuration and secret handling, where object graphs are converted to JSON for transport or persistence but sensitive members are intentionally ignored or transformed before write-out.
- Performance-sensitive services using source generation and System.Text.Json guidance to reduce runtime reflection while preserving explicit control over contract shape.
Why It Matters for Security Teams
For security teams, System.Text.Json matters because serialization defines the practical limit of data exposure. If the contract is too broad, sensitive properties can leak into logs, responses, caches, and downstream services even when application logic appears correct. If deserialisation is too permissive, untrusted JSON can populate fields that should never be client-controlled, creating integrity risk and weakening trust boundaries. This is especially important in identity-heavy systems where user profile data, authorization claims, session metadata, or NHI-related attributes may move between services as JSON. The security question is not whether JSON is used, but whether the serializer is operating with explicit allowlists, stable schema expectations, and reviewable exclusion rules. NIST’s guidance on secure software development and data protection supports this discipline, while OWASP’s API security guidance underscores how overexposed object graphs become a recurring source of leakage and mass assignment issues. Teams should treat serializer configuration as part of threat modelling, code review, and release governance, not as a cosmetic implementation choice. Organisations typically encounter the operational impact only after a response payload, audit export, or integration feed exposes data that was never intended to leave the system, at which point System.Text.Json becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Data security outcomes depend on controlling what JSON serialization reveals or accepts. |
| NIST SP 800-53 Rev 5 | SC-28 | Protecting data at rest and in transit depends on not serializing sensitive content unnecessarily. |
| OWASP Non-Human Identity Top 10 | NHI contexts often use JSON payloads for tokens, secrets, and agent metadata. | |
| NIST SP 800-63 | 3.1.2 | Identity data handling requires controlled disclosure of attributes and credentials. |
| OWASP Agentic AI Top 10 | Agentic systems often exchange JSON contracts that can leak tool inputs or outputs. |
Treat serializer settings as data protection controls and restrict output to approved fields.
Related resources from NHI Mgmt Group
- What breaks when a model can be persuaded to treat untrusted text as system-level instruction?
- When should organisations treat an AI agent as a privileged system?
- When should organisations treat an AI system as a non-human identity?
- What is the difference between agent skills and a large system prompt?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
