Skip to content

security(spp_dci_indicators): precompute/fetch_values route bypasses DCI-sync access gate [Severity: Medium] #349

Description

@gonzalesedwin1123

Deferred finding from the PR #234 access-control audit (internal/plans/pr234-dci-access-audit-findings.md, Finding 2). Confirmed real; filing for tracking (previously only noted in a PR #234 comment).

Finding

PR #234's _check_dci_sync_access guards only sync_for_partners(). A second route to the same outbound DCI fetch is not gated:

spp.data.cache.manager._compute_variable_values()   # spp_dci_indicators/models/data_cache_manager_dci.py:15-18
    -> spp.dci.cel.fetcher.fetch_values()            # outbound DCI call + cache write, runs as caller, no check

Reached via precompute_variable() in spp_cel_domain/models/data_evaluator.py (no access check), which a programs officer can trigger through cycle eligibility (spp_programs/models/managers/cycle_manager_base.pycheck_eligibility → precompute). So a programs officer can still trigger outbound fetches of disability/health data through that path, even though the directly-bindable surface (manual server action / sync) is now closed.

Design decision needed

Where to place the gate — fetcher vs cache-manager vs evaluator — without breaking the legitimate scheduled cron and cycle-eligibility precompute (which must keep working, likely via an env.su discriminator). The narrower reachability (needs a programs role + configured cycle) is why this was deferred rather than blocking.

Source: internal/plans/pr234-dci-access-audit-findings.md. Related: #234, PR #234 comment.

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