When every JSON payload is vetted against an access review, teams can guarantee that only authorized fields are exposed and that changes to data structures never bypass policy.
In practice, a JSON schema describes the shape of a document, its required properties, data types, and optional fields. An access review, on the other hand, is a periodic check that confirms who may read, write, or modify each piece of that document. The two intersect when a schema evolves: new fields appear, old ones are deprecated, and the review must be updated to reflect those changes. If the review lags behind the schema, developers may unintentionally expose sensitive attributes or allow unauthorized edits.
Because JSON is often transmitted over HTTP APIs, command‑line tools, or event streams, the point of enforcement must sit where the data actually flows. Relying solely on identity providers or static role assignments leaves a gap: the request reaches the target service before any policy can be applied, and there is no guarantee that the payload conforms to the latest review.
Why schema alone is insufficient for access reviews
JSON schema is a validation contract, not an access control mechanism. It can reject malformed data, but it cannot decide whether a particular user should see a given property. Conversely, an access review can list permissions, but without a runtime guard it cannot stop a request that includes disallowed fields. The missing piece is a data‑path component that can inspect each JSON message, compare it to the current schema, and enforce the review in real time.
Typical setups place the review process in a ticketing system or a spreadsheet. Those records are useful for audit, yet they do not intervene in the live traffic. When a developer pushes a new version of an API that adds a credit‑card number field, the access review may still say “only finance can see this,” but the API will happily return the value to any caller until the enforcement layer is updated.
Placing enforcement in the data path
The only reliable way to guarantee that access reviews are honoured is to interpose a gateway that sits between the caller and the JSON‑producing service. This gateway becomes the single point where every request is examined, where the current schema is loaded, and where the access‑review rules are applied. Because the gateway controls the traffic, it can:
- Mask or redact fields that the caller is not authorized to see.
- Block write operations that attempt to modify restricted properties.
- Route suspicious payloads to a human approver before they reach the backend.
- Record the entire session for replay and audit, providing concrete evidence for future reviews.
All of these outcomes depend on the gateway being in the data path; they cannot be achieved by identity configuration alone.
How hoop.dev provides the needed data‑path control
hoop.dev is an open‑source Layer 7 gateway that proxies connections to infrastructure, including HTTP APIs that serve JSON. It authenticates users via OIDC or SAML, reads group membership, and then applies policy at the protocol level. Because hoop.dev sits between the client and the target service, it can enforce access reviews on every JSON payload that passes through.
When a request arrives, hoop.dev loads the relevant JSON schema for that endpoint, evaluates the current access‑review rules, and either masks disallowed fields or blocks the operation entirely. The gateway also records the full request and response, creating an audit trail that can be inspected during future reviews. If a payload contains a newly added sensitive field, hoop.dev can automatically flag it for human approval before any data is leaked.
All enforcement outcomes, inline masking, command‑level blocking, just‑in‑time approval, and session recording, are possible only because hoop.dev occupies the data path. Identity providers and IAM roles decide who may start a session, but they do not enforce field‑level policies. hoop.dev fills that gap.
Running an access‑review‑aware JSON gateway
Deploying hoop.dev is straightforward: a Docker Compose file brings up the gateway and a network‑resident agent that sits next to your API service. The getting started guide walks you through connecting an HTTP endpoint, attaching a JSON schema, and defining access‑review rules in a policy file. Once configured, any client, whether a curl command, a browser, or an automated service, must go through hoop.dev to reach the API.
Because hoop.dev is MIT‑licensed and open source, you can inspect the code that performs masking and approval, extend the policy language, or integrate it with your existing ticketing system. The learn page contains deeper examples of how to model fine‑grained JSON field permissions and how to audit sessions after the fact.
Benefits for your access review process
- Continuous enforcement: Policies are applied on every request, eliminating the lag between a review decision and its technical enforcement.
- Real‑time masking: Sensitive fields are redacted before they leave the gateway, protecting downstream consumers.
- Audit evidence: Recorded sessions provide the exact data that was accessed, satisfying auditors who need proof of compliance.
- Just‑in‑time approvals: New or risky fields trigger a workflow that requires a human sign‑off before exposure.
By aligning JSON schema validation with access reviews inside a single gateway, organizations can close the gap that historically allowed data leaks despite documented permissions.
Getting started
To see the approach in action, clone the open‑source repository and follow the quick‑start steps. The repository includes example policies for JSON field masking and approval workflows.
View the open‑source repository on GitHub to begin securing your JSON APIs with access‑review‑driven enforcement.
