Add explicit checks for forbidden API only endpoints (future proofing)

[lucasmrod]

Related issue: Resolves #42887.

From Claude's audit:

[...]
Concerns worth addressing

A. Catalog drift is the real long-term risk. Today the yaml is curated. 
If a future engineer adds (say) POST /users/api_only, PATCH /users/api_only/:id, POST /users/roles/spec,
POST /password_reset, or any session-issuing route, an allowlisted api_only user can clone themselves or
broaden a peer's allowlist.
Suggest a CI test that hard-fails if any of those route prefixes show up in api_endpoints.yml,
plus a comment at the top of the yaml listing the categories that must never be added (user/role/invite/password/session/SSO).
[...]

Summary by CodeRabbit

• Tests
  • Added validation tests for API endpoint configuration to ensure security compliance and proper detection of restricted endpoint combinations.

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.

_{Tip: disable this comment in your organization's Code Review settings.}

[Copilot]

Pull request overview

Adds a new security-oriented test suite around server/api_endpoints/api_endpoints.yml so API-only endpoint allowlists cannot silently drift toward self-escalation paths.

Changes:

• Introduces blocklist rules for dangerous catalog entries under user, invite, and role-spec routes.
• Adds a test that fails if the embedded API endpoint catalog contains a forbidden route.
• Adds positive/negative sanity checks for the blocklist matcher.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

Caution

Review failed

Failed to post review comments

Walkthrough

This pull request adds a security-focused test suite to api_endpoints_test.go that enforces a blocklist of forbidden API endpoint method/path combinations. It introduces a catalogBlocklistRules structure containing regex patterns that identify restricted routes, a findBlocklistViolations matcher function that identifies violations, and the TestCatalogBlocklist test that validates the loaded API endpoint catalog against these rules, confirms each forbidden pattern is detected via example endpoints, and verifies legitimate endpoints are not incorrectly flagged.

Possibly related PRs

• Add gitops endpoints to api_endpoints catalog #44291: Extends api_endpoints.yml with new endpoints including GitOps configuration, which will be scanned by the new blocklist test.
• Update API endpoints list #44060: Makes large direct modifications to api_endpoints.yml, affecting the endpoints evaluated by the blocklist validation test.
• Remove non-existant routes #44093: Removes invalid routes from api_endpoints.yml, which impacts the validation results of the newly introduced blocklist checks.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main change: adding explicit checks for forbidden API-only endpoints as a security measure.
Description check	✅ Passed	The description provides context from the security audit, explains the risk of catalog drift, and outlines the solution, but lacks detail on implementation and testing.
Linked Issues check	✅ Passed	The PR implements explicit checks to prevent forbidden route combinations (users, roles, password, sessions) from being granted to API-only users, directly addressing issue #42887's requirement to detect and block privilege escalation scenarios.
Out of Scope Changes check	✅ Passed	All changes are focused on adding security validation tests for forbidden API-only endpoints, directly aligned with the issue's objectives to prevent catalog drift and privilege escalation.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch add-explicit-checks-for-forbidden-api-only-endpoints

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 7/8 reviews remaining, refill in 7 minutes and 30 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@server/api_endpoints/api_endpoints_test.go`:
- Around line 99-105: The catalogBlocklistRules array misses PUT as a mutation
method for user and invite modification entries: update the entries that
currently use "PATCH" for the regexp patterns matching
^/api/v1/fleet/users(?:/.*)?$ and ^/api/v1/fleet/invites(?:/.*)?$ to also block
"PUT" (i.e., add a separate rule for "PUT" or change the method field to include
PUT), ensuring the catalogBlocklistRule entries referencing those regexps cover
both PATCH and PUT; also update any related fault-injection examples and the
sanity-check list in the tests to include PUT-based mutation cases so the guard
is exercised for full-resource replacements as well.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: ff8d4248-dc76-4577-9f0e-e6dc6006d38e

📥 Commits

Reviewing files that changed from the base of the PR and between c6525b2 and c0be555.

📒 Files selected for processing (1)

• server/api_endpoints/api_endpoints_test.go

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 66.69%. Comparing base (2ee5404) to head (c0be555).
⚠️ Report is 15 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #44664   +/-   ##
=======================================
  Coverage   66.68%   66.69%           
=======================================
  Files        2651     2651           
  Lines      213493   213525   +32     
  Branches     9610     9610           
=======================================
+ Hits       142367   142404   +37     
+ Misses      58160    58159    -1     
+ Partials    12966    12962    -4     

Flag	Coverage Δ
backend	68.56% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nulmete]

LGTM.
Wondering if we want to also include some runtime validation within loadAPIEndpoints (right now we're just checking for duplicate entries, but perhaps we can introduce a similar validation that we have in these tests).

[lucasmrod]

@nulmete As long as we catch security issues in PR before merge to main we are good to go for now IMO.