Security: Gate header-driven ACL configuration behind trust boundary

[coderabbitai]

Description

Header-driven ACL configuration introduced in PR #337 needs security enhancements to prevent privilege escalation attacks. Currently, any client can spoof 'Tinyauth-Apps-...' headers to bypass access controls.

Security Concerns

• Clients can forge headers to escalate privileges
• No validation of request source or authenticity
• Feature enabled by default without safeguards

Required Security Measures

The DecodeHeaders(utils.NormalizeHeaders(...)) call in internal/controller/proxy_controller.go (around line 73) must be protected by:

1. Source IP Allowlist: Verify requests originate from trusted reverse proxies
2. HMAC Signature Validation: Validate X-Tinyauth-Signature header using shared secret
3. Feature Flag: Disable header-driven ACLs by default, require explicit enablement

Implementation Requirements

• Add configuration for trusted proxy IP allowlist
• Implement HMAC signature validation for headers
• Add feature flag to enable/disable header-driven ACLs (default: disabled)
• Update documentation with security considerations
• Provide sample reverse proxy configuration showing:
  • Trusted proxy IP setup
  • HMAC signature computation and transmission

References

• Original PR: feat: header based acls #337
• Security discussion: feat: header based acls #337 (comment)

[steveiliop56]

A simple TRUSTED_PROXIES environment variable will work perfectly for that.

[nicotsx]

I'm not sure a simple whitelist would be enough since a client could spoof any header of their request

Consider this attack vector:

1. Attacker discovers tinyauth is accessible on a network
2. finds a way to reach it from a trusted IP
3. sends: Tinyauth-Apps-Allow: * header
4. tinyauth would honor this header and grant full access

[steveiliop56]

This feature was a bad idea. It has been discarded and will not be implemented.

[mattberry1979]

@steveiliop56
In my comment to #275 I suggested that the ACLs come not from proxy headers (bad idea) or from labels (requires Docker-based deployment) but from matching the requested app domain against the user's group memberships returned by the OIDC or LDAP provider. That would keep all authentication and authorization config where it should be -- in LDAP or OIDC.

Perhaps that is a feasible alternative to proxy-based config?