Fehlende Zugriffskontrolle auf DELETE-Endpunkt

Der merged_router wird bei main.py:80 mit einem Read-Access-Guard registriert, enthält aber einen DELETE-Endpunkt, der eine destruktive Schreiboperation durchführt. Es gibt keine endpunktspezifische Autorisierung, die den Zugriff auf schreibberechtigte Benutzer einschränkt.

router.include_router(merged_router, dependencies=[Depends(has_read_access)])

Der DELETE-Endpunkt bei merged/main.py:64 erbt den Read-Access-Guard ohne Überschreibung:

@router.delete(
    "/merged-item/{identifier}", status_code=status.HTTP_204_NO_CONTENT, tags=["editor"]
)
def delete_merged_item(
    identifier: Annotated[Identifier, Path()],
    include_rule_set: Annotated[bool, Query(...)] = False,
) -> None:

Die Funktion has_read_access prüft lediglich, ob Credentials in der Read- oder Write-Datenbank vorhanden sind. Sie prüft nicht auf Schreibberechtigung und unterscheidet nicht nach HTTP-Methode:

if api_key:
    api_key_database = settings.backend_api_key_database
    can_read = APIKey(api_key) in api_key_database.read

Die Löschung kaskadiert: Ein einzelner DELETE-Request löscht das Merged Item, alle verknüpften Extracted Items (aus mehreren ETL-Pipelines), alle Rule-Sets und alle verschachtelten Objekte (Text, Link). Es gibt keinen Soft-Delete- oder Undo-Mechanismus. Die Wiederherstellung erfordert eine erneute Einspeisung aus allen Quell-ETL-Pipelines.

Im Gegensatz dazu verwendet der ingest_router bei main.py:77 korrekt Depends(has_write_access) und gibt für Read-only-Schlüssel den Statuscode 403 zurück.

Dieselbe Schwachstelle existiert in der Testanwendung bei testing/main.py:48.

Der DELETE-Endpunkt wurde in v1.2.0 (23.10.2025) eingeführt. Der merged_router wurde seit seiner Erstellung mit has_read_access registriert.

Der MEx-Editor verwendet derzeit einen gemeinsamen API Key mit Schreibberechtigung für alle Backend-Anfragen, unabhängig von der Benutzerrolle, und maskiert diese Schwachstelle in der Praxis. Allerdings enthält der Editor-Code ein TODO (MX-1616) für den Umstieg auf benutzerspezifische Backend-Credentials. Sobald diese Migration umgesetzt wird, wird die fehlende Autorisierung des Backends auf DELETE direkt über den Editor für jeden authentifizierten Benutzer ausnutzbar.