`ApiConfiguration` under `/admin` is readable by any `ROLE_USER` — `configJson` exposes upstream credentials

[schmunk42]

Problem

src/Entity/ApiConfiguration.php (master, unchanged as of 2026-08-23) restricts every write operation to ROLE_ADMIN, but leaves reads at ROLE_USER:

routePrefix: '/admin',
security: "is_granted('ROLE_USER')",

configJson is a plain readable property — no normalizationContext groups are declared on the resource, and ApiProperty defaults to readable: true:

#[ORM\Column(name: 'config_json', type: Types::JSON)]
#[JsonSchema]
#[Assert\NotBlank]
#[ApiConfigurationConstraint]
#[ApiProperty(description: 'API configuration object. Must match one of the supported API types.')]
private array $configJson = [];

configJson is exactly where credentials for the upstream system live — the field's own JSON schema models auth_type: basic|bearer with username/password or token. So any authenticated user can read the credentials of every configured upstream API via GET /api/admin/api_configurations.

In our case one configuration holds HTTP basic credentials for a workflow engine whose REST API can deploy processes and mutate process state, and another holds a bearer token for an upstream data service. Any user who can obtain a token for the application — including the lowest-privileged domain role — can read both and then talk to those systems directly, bypassing the application entirely.

This is not merely a matter of degree versus the Job-resource case in the sibling bundle: read access to a credential store is a privilege escalation, not an information leak.

Why this looks like an oversight

The write operations were deliberately narrowed to ROLE_ADMIN (Post, Put, Patch, Delete, and the …/authorize sub-resource), and the resource sits behind routePrefix: '/admin' with openapi: new Operation(tags: ['System']). Everything about the resource says "operations only" except the read default. The sibling bundles that expose operational resources under /admin (doctrine-audit-log-bundle → LogEntry, symfony-system-resources-bundle → DoctrineMigrationVersion / MessengerMessage) all default to ROLE_ADMIN.

Proposal

Both parts, not either/or:

1. Resource default → ROLE_ADMIN (security: "is_granted('ROLE_ADMIN')"), matching the write operations and the sibling bundles. The …/health sub-resource can stay broader if consumers rely on it for status displays — it exposes no secrets.
2. Never serialize secrets, regardless of the role. Even for an admin, returning password / token over the API is more than the resource needs. Options, roughly in order of preference:
   • redact known credential keys in a normalizer/output DTO (password, token, secret, *_secret) so the shape stays intact but values are masked;
   • or #[ApiProperty(security: "is_granted('ROLE_ADMIN')")] on configJson as a minimum step;
   • long term, keep secrets out of the row entirely (env/secret-store reference in configJson, resolved server-side). We already do this in one application for a client secret specifically because configJson is API-readable — it would be good if the bundle made that the default rather than something each consumer has to remember.

Impact

Breaking for consumers whose non-admin clients read the configuration list (e.g. to discover a base URL). Suggest a config option or a reduced read projection for that use case rather than keeping the current default.

Notes for the fix

• Regression tests worth having: authenticated non-admin gets 403 on collection and item; an admin read does not contain the credential values.
• Reproduction is straightforward: seed a configuration with auth_type: basic, then GET /api/admin/api_configurations with a token that carries only the baseline authenticated role.

---

Reported with AI assistance (Claude Code).

[schmunk42]

Verified against a running stack — the original report was derived from reading the resource metadata; this is the same thing observed over HTTP.

Setup: an OIDC access token for a user whose realm roles map to the baseline authenticated role only (ROLE_USER, no ROLE_ADMIN), against an application with three seeded configurations.

GET /api/admin/api_configurations
→ 200 OK, hydra:totalItems = 3

configJson is serialized for all three items. For the configuration using auth_type: basic the response contains both username and a non-empty password; for a bearer one it contains token. The password value in the response is byte-identical to the credential the application itself uses to authenticate against that upstream system — so it is the live secret, not a placeholder. (Values were compared programmatically and never printed.)

This confirms there is no implicit filtering anywhere in the chain: with no normalizationContext groups declared on the resource and ApiProperty.readable defaulting to true, the credential fields go out as-is to any authenticated caller.

Two small notes for whoever picks this up:

• The read side is the whole issue — the write operations are already correctly restricted to ROLE_ADMIN, so a consumer cannot change a configuration, only read every secret in it.
• Because the values live in the row, a fix that only tightens the route still leaves the secrets in the database and in any dump or backup of it. That is why the suggestion above has two parts (tighten the default and stop serializing credential keys) rather than one.

---

Verification with AI assistance (Claude Code).

[schmunk42]

Note for implementation: We do NOT need the old option (via config or fallback), reads only for ROLE_ADMIN.