Skip to content

security(info-disclosure): ArchivalController::getDestructionList returns 500 (SQL leak) for unknown id instead of 404 #2146

Description

@rubenvdlinde

Flagged during the tests/integration Newman remediation (PR #2145). Same class as the TmloController bug fixed there.

Bug: GET /api/archival/destruction-lists/{bogus-id} returns HTTP 500 with an HTML error page (and, like the TMLO case, risks leaking the raw DBAL SQL) when the id/register/schema doesn't exist — because RegisterMapper::find/lookup throws DoesNotExistException which is swallowed by a generic catch and surfaced as a 500 rather than a clean JSON 404.

Fix direction: in ArchivalController::getDestructionList (and audit sibling methods for the same pattern), catch DoesNotExistException explicitly and return a clean 404 JSON body — mirroring the fix applied to TmloController::summary/exportSingle/exportBatch in #2145. Add a Newman/unit guard asserting 404 (not 500) for an unknown id.

Also noted (lower priority): emails/search and integrations/email/accounts are 501 stubs — expected/known, listed here for visibility.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions