# Review access when a response gains new fields

An additive field can expose information to every existing caller. Evaluate its audience and data meaning before treating it as a harmless schema extension.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Identify who already receives the response

List the roles and integrations permitted to call the endpoint. A new internal note or account attribute may be suitable for one audience and inappropriate for another that already has access to the basic resource.

Do not assume resource-level read permission covers every future field. The application may need field-level shaping or a separate operation for more sensitive information.

Review cached and exported responses too. Adding a field can cause existing logs, analytics or client storage to retain information they never handled before.

## Construct the public response deliberately

Map approved fields from the domain record into a response contract. Avoid serialising an entire database entity, where a storage change can accidentally become an API disclosure.

Use trusted caller context to select the permitted representation. A client-supplied role or includeSensitive flag should not grant access without server-side authority checks.

Keep absent, redacted and null values meaningful. Do not reveal the existence of restricted information through a new field state unless that disclosure is intended.

## Inspect indirect consumers

Generated SDKs, web clients and integrations may forward the response to their own systems. The API owner cannot necessarily control every downstream copy, so minimise the data exposed by default.

Check error responses and debugging endpoints for the same field. A secure success serializer can be undermined by an exception that includes the full internal object.

If a new field is only needed for one workflow, consider a narrower endpoint or explicit authorised expansion rather than adding it universally.

## Test old and new audiences

Use callers with different permissions to request the same resource and inspect the exact response fields. Include direct API calls, caches and supported exports.

Run compatibility checks as well as access checks. A field may be appropriately disclosed but still break a strict client parser. Both properties matter to a successful release.

Record the field's audience, purpose and retention implications in the contract review. An additive change is safe only when both the caller behaviour and the information exposure remain within the intended promise.

## Sources

- [OWASP: authorisation guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
- [Google AIP-180: backwards compatibility](https://google.aip.dev/180)