Sentry SecurityCAUTION

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: sentry-security
description: 'Sentry-specific security review based on real vulnerability history. Use when reviewing Sentry endpoints, serializers, or views for security issues. Trigger keywords: "sentry security review", "check for IDOR", "access control review", "org scoping", "cross-org", "security audit endpoint".'
allowed-tools: Read Grep Glob Bash
---

# Sentry Security Review

Find security vulnerabilities in Sentry code by checking for the patterns that have caused real vulnerabilities in this codebase.

This skill is Sentry-specific. It encodes patterns from 37 real security patches shipped in the last year — not generic OWASP theory.

## Scope

Review the code provided by the user (file, diff, or endpoint). Research the codebase as needed to build confidence before reporting.

Report only **HIGH** and **MEDIUM** confidence findings. Do not report theoretical issues.

| Confidence | Criteria                                   | Action                       |
| ---------- | ------------------------------------------ | ---------------------------- |
| **HIGH**   | Traced the flow, confirmed no check exists | Report with fix              |
| **MEDIUM** | Check may exist but could not confirm      | Report as needs verification |
| **LOW**    | Theoretical or mitigated elsewhere         | Do not report                |

## Step 1: Classify the Code

Determine what you're reviewing and load the relevant reference.

| Code Type                                | Load Reference                       |
| ---------------------------------------- | ------------------------------------ |
| API endpoint (inherits from `*Endpoint`) | `references/endpoint-patterns.md`    |
| Serializer or form field                 | `references/serializer-patterns.md`  |
| Email template or HTML rendering         | `references/output-sanitization.md`  |
| Token, OAuth, or session handling        | `references/token-lifecycle.md`      |
| Role or permission logic                 | `references/privilege-escalation.md` |

If the code spans multiple categories, load all relevant references.

**Always load** `references/enforcement-layers.md` — it documents where security checks can legitimately live in Sentry's request lifecycle. A check in any layer counts as enforcement.

## Step 2: Check for the Top 6 Vulnerability Classes

These are ordered by frequency from the last year of real patches.

### Check 1: Cross-Org Object Access (IDOR) — 9 patches last year

The most common vulnerability. An endpoint accepts an ID from the request but does not scope the query by the organization from the URL.

**Trace this flow for every ID that comes from the request:**

```
1. Where does the ID enter? (query param, request body, URL kwarg)
2. Where is it used in an ORM query?
3. Between (1) and (2), is the query scoped by organization_id or project_id
   from the URL (NOT from the request body)?
```

**Red flags:**

- `Model.objects.get(id=request.data["something_id"])` — no org scope
- `Model.objects.filter(id=request.GET["id"])` — no org scope
- `project_id` from request body/query used directly without `Project.objects.filter(id=pid, organization_id=organization.id)`
- Endpoint inherits `OrganizationEndpoint` but handler method does not accept or use the `organization` parameter

**Safe patterns:**

- Query includes `organization_id=organization.id` where `organization` comes from `convert_args()`
- Uses `self.get_projects()` which scopes by org internally
- Object is fetched via URL kwargs resolved by `convert_args()`
- Unscoped query is a guard that only raises an error (never returns data), AND
  a downstream query in the same flow IS org-scoped and raises the same error —
  no differential behavior means no information leak

### Check 2: Missing Authorization Checks — 10 patches last year

An endpoint or serializer performs a sensitive operation without verifying the user has permission.

**Check:**

- Does the endpoint inherit from the right base class? (`OrganizationEndpoint`, `ProjectEndpoint`, etc.)
- Does it declare `permission_classes`? If not, it inherits the base class default — verify that's appropriate.
- For serializer fields that reference other objects: do they validate the user can access those objects?
- For Django views (not DRF): is there a `@login_required` or equivalent?

### Check 3: Privilege Escalation / Role Abuse — 3 patches last year

A user can assign ownership, modify roles, or escalate access beyond what their role allows.

**Check:**

- Owner/assignee fields: uses `OwnerActorField` (validates membership), NOT `ActorField` (allows any actor)
- Role modification endpoints: verify the requesting user's role is >= the target role
- Team assignment: verify the user is a member of the target team (or has `team:admin`)

### Check 4: Token / Session Security — 5 patches last year

Token lifecycle gaps that allow unauthorized access.

**Check:**

- Token refresh: is the application's active status checked before granting a refresh?
- Org-level tokens: is `organization_id` required and validated?
- Member status: is the member's enabled/disabled status checked before granting tokens?
- Impersonation: are impersonated sessions rate-limited?

### Check 5: Output Sanitization (XSS/HTML Injection) — 4 patches last year

User-controlled strings rendered unsafely in emails, markdown, or HTML.

**Check:**

- User display names, team names, org names used in email templates: are they sanitized?
- Markdown rendering: is custom CSS or HTML allowed through?
- `format_html()` vs string concatenation in templates
- `mark_safe()` called on user input

### Check 6: Auth/MFA Gaps — 3 patches last year

Authentication state inconsistencies.

**Check:**

- When removing an authenticator: are recovery codes cleaned up?
- CSRF token handling: is it synced across tabs/windows?
- Session invalidation: does removing auth factors properly invalidate sessions?

**If no checks produced a potential finding, stop and re

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (6)

.claude/skills

api-docs/.node-version

- **Centralized enforcement** — the check runs in a permission class inherited by all endpoints within the affected scope. The credential cannot reach any endpoint that lacks the check. Classify as **

**Example (LOW — centralized):** OAuth authorize view issues a token to a `member-limit:restricted` member. The token exists, but `is_member_disabled_from_limit()` in `OrganizationPermission.determine

**Example (MEDIUM — scattered):** A token is issued without checking X, and X is only validated in specific endpoint subclasses (not the base). Some endpoints may not inherit the check. Report as need

**Known downstream enforcement:** PR #92616 added `is_member_disabled_from_limit()` checks via the organization permission base class. This is **centralized enforcement** — the check runs for every or

Gates applied: no_behavioural_pass.