fix: refuse a stranger TPP reading a consent's status or SCA status

[hongwei1]

Four endpoints read a Berlin Group consent by id. Two compared the consent’s lodging Consumer against the caller’s; two did not.

Endpoint	Ownership check before	After
GET /consents/{id}	yes	yes
GET /consents/{id}/authorisations	yes	yes
GET /consents/{id}/status	no	yes
GET /consents/{id}/authorisations/{authorisationId}	no	yes

Both unguarded routes were already fetching the consent — to prove it exists — and then simply did not look at who was asking. The consent id alone therefore confirmed a consent existed and let its progress through authorisation be watched from outside. The PUT that answers an authorisation is guarded, so this disclosed state rather than granting access.

Verified against a running instance

Two TPPs: A lodges the consent, B is a stranger holding valid AISP credentials.

Before:

TPP B -> GET /consents/{id}                 403  refused
TPP B -> GET /consents/{id}/authorisations  403  refused
TPP B -> GET /consents/{id}/status          200  LEAKED consentStatus
TPP B -> GET /consents/{id}/auth/{aid}      200  LEAKED scaStatus

After — all four refuse the stranger and all four still serve the lodging TPP:

GET /consents/{id}                  stranger=403  owner=200
GET /consents/{id}/authorisations   stranger=403  owner=200
GET /consents/{id}/status           stranger=403  owner=200
GET /consents/{id}/auth/{aid}       stranger=403  owner=200

code.api.berlin.group 183/183. Full local probe matrix 101/101.

Why it was missed

The probe added when the first of these was fixed asserted only the endpoint that had been noticed, so the other three were never examined. It now walks the whole family — which is what surfaced the two that were still open.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud