Misclassifying sensitive data in JSON payloads can expose a breach in seconds.
Why data classification matters for JSON schema
JSON schema is the lingua franca for validating API contracts, configuration files, and event streams. When a schema merely checks shape and type, it provides no guarantee that the values it carries are handled according to their sensitivity. Teams often rely on informal naming conventions, "ssn" or "creditCard", and hope that downstream services respect those hints. In practice, developers copy‑paste schemas across repositories, forget to update classification tags, and ship payloads that contain personal identifiers, health data, or secret keys without any technical guardrails.
This lax approach creates three hidden risks. First, a developer may accidentally log a field that should be redacted, leaking it to a centralized log aggregator. Second, automated pipelines that forward JSON to third‑party services can exfiltrate regulated data unnoticed. Third, incident responders lose visibility because there is no reliable record of the raw payloads.
Current practice and its gaps
Most organizations embed classification metadata as free‑form comments inside a schema file or as a separate mapping table. The process looks like this:
- Define the JSON schema for a service.
- Maintain a spreadsheet that lists each property and its classification level (public, internal, confidential, restricted).
- Rely on developers to remember to consult the spreadsheet before writing log statements or sending data downstream.
Because the classification lives outside the data path, there is no technical enforcement. The request reaches the downstream system directly, carrying the raw payload. No audit log captures which fields were transmitted, no inline masking strips sensitive values, and no just‑in‑time approval step can intervene when a high‑risk field appears in a request.
Embedding classification in the data path
To close the gap, classification must become part of the runtime access surface. The ideal solution places a gateway between the client that produces JSON and the target service that consumes it. This gateway reads the schema, understands the classification tags, and applies three controls:
- It masks or redacts fields marked as confidential before the payload leaves the controlled zone.
- It records the request and response, preserving evidence of what data moved and who initiated the transaction.
- It can pause a request that contains restricted data until a human reviewer approves it.
All of these actions happen on the wire, without requiring developers to add custom code to each service. The gateway becomes the single source of truth for data classification enforcement.
How hoop.dev enforces data classification
hoop.dev provides exactly that data‑path gateway. It sits at Layer 7, parses JSON traffic, and applies classification policies defined in the schema. When a request arrives, hoop.dev inspects each property, matches it against the classification tags, and takes the appropriate action:
- hoop.dev masks classified fields in responses, ensuring downstream logs never contain raw values.
- hoop.dev records every JSON exchange, creating an audit trail that auditors can query for evidence of compliance.
- hoop.dev routes high‑risk payloads to a just‑in‑time approval workflow, letting a security analyst approve or reject the transaction before it reaches the target service.
Because hoop.dev is the only point where the traffic is inspected, these outcomes exist only because the gateway is present. If the gateway were removed, the raw JSON would flow directly to the service with no masking, no audit, and no approval step.
Getting started with classification‑aware JSON handling
Begin by extending your JSON schema with a classification keyword for each property. The hoop.dev documentation explains the supported syntax and how to map classification levels to enforcement actions. Deploy the hoop.dev gateway using the Docker Compose quick‑start, configure it to trust your OIDC identity provider, and register the JSON‑based service as a connection. Once the gateway is running, all traffic to that service automatically benefits from the classification controls described above.
For detailed steps, see the getting‑started guide and the broader learn section. The open‑source repository on GitHub contains the full source code and example configurations: Explore hoop.dev on GitHub.
FAQ
Do I need to change my existing services to use hoop.dev?
No. hoop.dev acts as a transparent proxy. Your services continue to listen on the same ports and use the same client libraries. The only change is the endpoint address, which now points to the gateway.
Can I use hoop.dev with multiple classification schemes?
Yes. The gateway can load different policy files per connection, allowing you to enforce PCI‑DSS, HIPAA, or custom internal classifications side by side.
Is the audit log tamper‑proof?
hoop.dev writes each session to a storage backend that is separate from the client process. While the exact durability guarantees depend on the chosen backend, the design ensures that the audit trail cannot be altered by the client that generated the request.
