Description
The backend's core purpose is orchestrating security scans (recon, web, cloud, container workflows per the documented plugin categories) via FastAPI endpoints. Nothing in the README's API/architecture documentation (Swagger docs are mentioned as available at /docs, but no auth/rate-limiting middleware is mentioned anywhere in the Tech Stack or Repository Map) indicates that scan-triggering endpoints are protected by authentication or throttled against repeated rapid triggering.
Since scans can involve external network activity (recon against real targets, per the "Responsible Use" section), an unauthenticated or unthrottled scan-trigger endpoint is a real risk vector: anyone with network access to the backend (see Issue 2.2 above — which could be wider than intended) could trigger repeated, resource-intensive, or externally-directed scans without any accountability or logging of who initiated them.
Impact
Combined with Issue 2.2, this compounds into a real risk: an accidentally-network-exposed backend with no auth on scan endpoints means anyone on the network could trigger scans against arbitrary targets using this project's infrastructure.
No audit trail of "who triggered this scan" undermines the project's own "ethical and learning-oriented usage" framing.
Proposed Solution
Add a lightweight local-auth mechanism (API key or session-based, appropriate for a local-first tool — doesn't need full multi-tenant auth) to scan-triggering endpoints specifically.
Add rate limiting (e.g., slowapi for FastAPI) on scan-trigger routes to prevent rapid repeated triggering.
Log every scan trigger with a timestamp and (if auth is added) the requesting identity, surfaced in the frontend dashboard for auditability.
Document this security model explicitly in SECURITY.md, given it already exists and is the natural home for this.
Acceptance Criteria
Scan-trigger endpoints require some form of local authentication
Rate limiting implemented on scan-trigger routes
Every triggered scan is logged with a timestamp and identity where available
SECURITY.md documents the access-control model for scan endpoints
Description
The backend's core purpose is orchestrating security scans (recon, web, cloud, container workflows per the documented plugin categories) via FastAPI endpoints. Nothing in the README's API/architecture documentation (Swagger docs are mentioned as available at /docs, but no auth/rate-limiting middleware is mentioned anywhere in the Tech Stack or Repository Map) indicates that scan-triggering endpoints are protected by authentication or throttled against repeated rapid triggering.
Since scans can involve external network activity (recon against real targets, per the "Responsible Use" section), an unauthenticated or unthrottled scan-trigger endpoint is a real risk vector: anyone with network access to the backend (see Issue 2.2 above — which could be wider than intended) could trigger repeated, resource-intensive, or externally-directed scans without any accountability or logging of who initiated them.
Impact
Combined with Issue 2.2, this compounds into a real risk: an accidentally-network-exposed backend with no auth on scan endpoints means anyone on the network could trigger scans against arbitrary targets using this project's infrastructure.
No audit trail of "who triggered this scan" undermines the project's own "ethical and learning-oriented usage" framing.
Proposed Solution
Add a lightweight local-auth mechanism (API key or session-based, appropriate for a local-first tool — doesn't need full multi-tenant auth) to scan-triggering endpoints specifically.
Add rate limiting (e.g., slowapi for FastAPI) on scan-trigger routes to prevent rapid repeated triggering.
Log every scan trigger with a timestamp and (if auth is added) the requesting identity, surfaced in the frontend dashboard for auditability.
Document this security model explicitly in SECURITY.md, given it already exists and is the natural home for this.
Acceptance Criteria
Scan-trigger endpoints require some form of local authentication
Rate limiting implemented on scan-trigger routes
Every triggered scan is logged with a timestamp and identity where available
SECURITY.md documents the access-control model for scan endpoints