Summary
Frigate's go2rtc API proxy allows authenticated viewer users to access sensitive GET endpoints without administrator authorization. This may expose internal addresses, configuration details, logs, stack data, and RTSP URLs that can contain camera credentials.
Affected context
The issue occurs in Frigate deployments where the NGINX configuration exposes the prefix-matched /api/go2rtc/api location to authenticated users. Although access requires authentication, GET requests are not restricted to administrator roles, allowing viewer accounts to reach selected go2rtc API subpaths. Non-GET methods remain restricted, so the exposure is primarily read-oriented.
Exploit preconditions
- Attack surface: The Frigate HTTP API proxy for go2rtc
- Required access: An authenticated account with viewer-level permissions
- Trigger point: GET requests to exposed go2rtc API subpaths, including streams, config, log, and stack
- Why exploitation is possible: Authorization checks distinguish authentication from administrative privilege and permit viewer access to sensitive read operations
Why this happens
The underlying flaw is an authorization boundary failure. The proxy requires a valid session but does not consistently enforce the administrator role for sensitive GET requests, allowing a lower-privileged user to access information intended for more trusted operators. This behavior maps to CWE-863: Incorrect Authorization, where access-control decisions do not properly reflect the required privilege level.
Potential impact
- Viewer users may obtain internal service addresses and configuration paths
- Application logs may reveal operational details or sensitive data
- Goroutine stack information could disclose implementation and runtime details
- RTSP stream URLs may expose camera credentials
- Attackers could use disclosed information to target cameras or related services
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every sensitive API boundary rather than relying on authentication alone.
Common defensive patterns include:
- Require administrator authorization for configuration, diagnostic, logging, and stream-management endpoints
- Apply consistent role checks to proxied routes and every supported HTTP method
- Use explicit allowlists for endpoints accessible to viewer roles
- Avoid embedding long-lived credentials in URLs where possible
- Redact secrets from logs, diagnostics, and API responses
- Apply least privilege to user accounts and service integrations
- Treat internal addresses and operational metadata as sensitive information
How teams detect issues like this
Organizations can detect similar authorization issues through:
- Static and dynamic analysis of route definitions and role-check middleware
- Code review checks for authentication checks that lack role or capability checks
- Tests that exercise every sensitive endpoint with viewer, operator, and administrator identities
- Proxy and application logs showing viewer accounts requesting diagnostic or configuration paths
- Policy enforcement requiring explicit authorization annotations for privileged API routes
- Automated API security testing that compares responses across user privilege levels
