Gate /debug endpoints out of production

Offen
  • Stimmt etwas nicht?
#84 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
30/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
fastapi, python, typescript
Bereich
api, authentication, backend, security

Rechercherichtung

Beginne in src/smartem_backend/api_server.py bei den Definitionen der Debug-Routen und prüfe, wie die Konfiguration behandelt wird; lies anschließend tests/smartem_backend/test_debug_sessions.py und die in der Issue erwähnten Referenzen zum generierten Client. Die Arbeit ist abgeschlossen, wenn ein abgestimmter Ansatz die Debug-Endpunkte wie vorgesehen einschränkt, entfernt oder ausschließt und die betroffenen Tests sowie die generierten Ausgaben aktualisiert sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

security

Narrowed from the original "Address API vulnerability". The vulnerability as originally
described - debug endpoints reachable with no authentication at all - has been fixed. What
remains is a smaller, concrete hardening task, retained here so it is not lost.

What changed since this was filed

verify_token is now attached to the FastAPI application itself
(src/smartem_backend/api_server.py), so it applies to every route. EXEMPT_PATHS in
src/smartem_backend/auth.py covers only /health, /status, /openapi.json, /docs and
/redoc - no debug paths. Reaching any /debug/* endpoint now requires a valid Keycloak token.

What is still outstanding

1. The endpoints are not gated by environment. The original recommendation had two parts:
authenticate them, and conditionally disable them in production. The first is done; the second
was never implemented. There is no configuration flag or environment check governing them.

All eight remain registered, including write operations:

  • GET /debug/agent-connections
  • GET /debug/sessions
  • GET /debug/connection-stats
  • GET /debug/session/{session_id}/instructions
  • POST /debug/sessions/create-managed
  • POST /debug/sessions/create
  • POST /debug/session/{session_id}/create-instruction
  • DELETE /debug/sessions/{session_id}/close

2. They have no production consumer. The only references anywhere are
tests/smartem_backend/test_debug_sessions.py (added under #258) and the frontend's
generated MSW mock handlers - and those exist only because the endpoints appear in the
OpenAPI spec, not because the front end calls them.

3. They propagate into the published spec. Because they are in the OpenAPI document, they
flow into the generated frontend client and mocks, and into any other consumer generated from
that spec.

4. Authentication is not authorisation. Token claims are validated but are not used to
scope access, so a valid token is not currently constrained to its own session's data. That is
a broader piece of work and is deliberately not in scope here - it was recorded on #85 when
that issue was closed.

Options

Not picking one up front; they trade off differently:

  • Environment gating - register the debug routes only when a configuration flag is set.
    Keeps them available in development, removes them entirely from production.
  • include_in_schema=False - keeps the endpoints but drops them from the OpenAPI document,
    so they stop propagating into the generated client and mocks. Addresses (3) but not (1).
  • Removal - they have no production consumer. The only cost is test_debug_sessions.py,
    which was written for #258 and would go with them.

Gating and schema exclusion are complementary rather than alternatives.

Code references

  • src/smartem_backend/api_server.py - debug route definitions, and the app-level
    dependencies=[Depends(verify_token)]
  • src/smartem_backend/auth.py - EXEMPT_PATHS
  • tests/smartem_backend/test_debug_sessions.py - sole test consumer
Vorherrschende Sprache
TypeScript
Sterne
0
Forks
0
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus DiamondLightSource/smartem-devtools

Alle Issues in DiamondLightSource/smartem-devtools

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.