weco-security-boundary-review

Reviews access control boundaries in views, API endpoints, forms, and models with negative tests.

Updated Jun 13, 2026
One-click install
npx skills add https://github.com/malinovskiy-makar/qls --skill weco-security-boundary-review-malinovskiy-makar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: weco-security-boundary-review
Source: https://github.com/malinovskiy-makar/qls/tree/main/.claude/skills/weco-security-boundary-review
Command: npx skills add https://github.com/malinovskiy-makar/qls --skill weco-security-boundary-review-malinovskiy-makar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code changes to views, API endpoints, forms, or roles can silently open access to resources that should be restricted, and reading the code alone rarely proves the boundary holds. This Skill enforces a systematic access-control review that proves every boundary with a negative test rather than an assumption. ## Core Features & Use Cases - Resource-Role-Action Matrix: Builds a table of who can do what across roles (anonymous, student, tutor, parent, admin) and flags cells where permission exists without a code check. - Ownership and Queryset Audits: Verifies owners come from request.user rather than client data, and that object lookups filter by owner instead of bare primary keys. - Mandatory Negative Tests: Requires a test proving an outsider gets 403 or 404 for every boundary, such as another tutor accessing a student of a different tutor. - Use Case: After adding a new endpoint that returns a student's submission, run this review to confirm the queryset is filtered by the requesting tutor, the decorator is in place, and a test proves another tutor receives 403. ## Quick Start Review the access boundaries of the views and endpoints I just changed and confirm each one is covered by a negative permission test.

Frequently Asked Questions about weco-security-boundary-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review access control when adding a new API endpoint?

Build a resource-role-action matrix for the affected resources, verify the endpoint has a login or role decorator, and confirm object lookups filter by owner. Then write a negative test proving an unauthorized user receives 403 or 404.

How to check Django views for broken object-level permissions?

Search for get_object_or_404 calls that filter only by primary key without an owner condition, since those return other users' objects to anyone who knows the ID. Add an owner filter such as owner=request.user or an explicit 403 check.

Is a long UUID or token URL enough to protect sensitive data?

No, an unguessable link is not an access right because links leak through messages, browser history, and screenshots. Sensitive data behind a link still requires a proper permission check, not just token length.

Why is a positive permission test not enough for access control?

A test showing the owner can access a resource never proves others cannot. Every boundary needs a paired negative test where an outsider, such as another tutor or an anonymous user, receives 403 or 404.

When should this access boundary review not be used?

Skip it for template and style changes that do not alter access logic. It is intended for changes to views, endpoints, forms, access decorators, owner fields, models with owners, or the introduction of new roles.