[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-6db19e1a-2645-4c27-a00c-d69371672194":3,"$f6xPivJ38pRp1XqctclatIU1u-Qw2uYqbrHzlLk1umDs":42},{"id":4,"title":5,"description":6,"categoryId":7,"moduleId":8,"tags":9,"prompt":10,"icon":11,"source":12,"sourceUrl":13,"authorId":14,"authorName":15,"isPublic":16,"stars":17,"runs":18,"createdAt":19,"updatedAt":19,"module":20,"category":27,"packages":33},"6db19e1a-2645-4c27-a00c-d69371672194","django-access-review","Django访问审查","cat_coding_backend","mod_coding","sickn33,coding","---\nname: django-access-review\ndescription: django-access-review\nrisk: unknown\nsource: community\n---\n\n---\nname: django-access-review\ndescription: Django access control and IDOR security review. Use when reviewing Django views, DRF viewsets, ORM queries, or any Python\u002FDjango code handling user authorization. Trigger keywords: \"IDOR\", \"access control\", \"authorization\", \"Django permissions\", \"object permissions\", \"tenant...\n--- LICENSE\n---\n\n\u003C!--\nReference material based on OWASP Cheat Sheet Series (CC BY-SA 4.0)\nhttps:\u002F\u002Fcheatsheetseries.owasp.org\u002F\n-->\n\n# Django Access Control & IDOR Review\n\nFind access control vulnerabilities by investigating how the codebase answers one question:\n\n**Can User A access, modify, or delete User B's data?**\n\n## When to Use\n- You need to review Django or DRF code for access control gaps, IDOR risk, or object-level authorization failures.\n- The task involves confirming whether one user can access, modify, or delete another user's data.\n- You want an investigation-driven authorization review instead of generic pattern matching.\n\n## Philosophy: Investigation Over Pattern Matching\n\nDo NOT scan for predefined vulnerable patterns. Instead:\n\n1. **Understand** how authorization works in THIS codebase\n2. **Ask questions** about specific data flows\n3. **Trace code** to find where (or if) access checks happen\n4. **Report** only what you've confirmed through investigation\n\nEvery codebase implements authorization differently. Your job is to understand this specific implementation, then find gaps.\n\n---\n\n## Phase 1: Understand the Authorization Model\n\nBefore looking for bugs, answer these questions about the codebase:\n\n### How is authorization enforced?\n\nResearch the codebase to find:\n\n```\n□ Where are permission checks implemented?\n  - Decorators? (@login_required, @permission_required, custom?)\n  - Middleware? (TenantMiddleware, AuthorizationMiddleware?)\n  - Base classes? (BaseAPIView, TenantScopedViewSet?)\n  - Permission classes? (DRF permission_classes?)\n  - Custom mixins? (OwnershipMixin, TenantMixin?)\n\n□ How are queries scoped?\n  - Custom managers? (TenantManager, UserScopedManager?)\n  - get_queryset() overrides?\n  - Middleware that sets query context?\n\n□ What's the ownership model?\n  - Single user ownership? (document.owner_id)\n  - Organization\u002Ftenant ownership? (document.organization_id)\n  - Hierarchical? (org -> team -> user -> resource)\n  - Role-based within context? (org admin vs member)\n```\n\n### Investigation commands\n\n```bash\n# Find how auth is typically done\ngrep -rn \"permission_classes\\|@login_required\\|@permission_required\" --include=\"*.py\" | head -20\n\n# Find base classes that views inherit from\ngrep -rn \"class Base.*View\\|class.*Mixin.*:\" --include=\"*.py\" | head -20\n\n# Find custom managers\ngrep -rn \"class.*Manager\\|def get_queryset\" --include=\"*.py\" | head -20\n\n# Find ownership fields on models\ngrep -rn \"owner\\|user_id\\|organization\\|tenant\" --include=\"models.py\" | head -30\n```\n\n**Do not proceed until you understand the authorization model.**\n\n---\n\n## Phase 2: Map the Attack Surface\n\nIdentify endpoints that handle user-specific data:\n\n### What resources exist?\n\n```\n□ What models contain user data?\n□ Which have ownership fields (owner_id, user_id, organization_id)?\n□ Which are accessed via ID in URLs or request bodies?\n```\n\n### What operations are exposed?\n\nFor each resource, map:\n- List endpoints - what data is returned?\n- Detail\u002Fretrieve endpoints - how is the object fetched?\n- Create endpoints - who sets the owner?\n- Update endpoints - can users modify others' data?\n- Delete endpoints - can users delete others' data?\n- Custom actions - what do they access?\n\n---\n\n## Phase 3: Ask Questions and Investigate\n\nFor each endpoint that handles user data, ask:\n\n### The Core Question\n\n**\"If I'm User A and I know the ID of User B's resource, can I access it?\"**\n\nTrace the code to answer this:\n\n```\n1. Where does the resource ID enter the system?\n   - URL path: \u002Fapi\u002Fdocuments\u002F{id}\u002F\n   - Query param: ?document_id=123\n   - Request body: {\"document_id\": 123}\n\n2. Where is that ID used to fetch data?\n   - Find the ORM query or database call\n\n3. Between (1) and (2), what checks exist?\n   - Is the query scoped to current user?\n   - Is there an explicit ownership check?\n   - Is there a permission check on the object?\n   - Does a base class or mixin enforce access?\n\n4. If you can't find a check, is there one you missed?\n   - Check parent classes\n   - Check middleware\n   - Check managers\n   - Check decorators at URL level\n```\n\n### Follow-Up Questions\n\n```\n□ For list endpoints: Does the query filter to user's data, or return everything?\n\n□ For create endpoints: Who sets the owner - the server or the request?\n\n□ For bulk operations: Are they scoped to user's data?\n\n□ For related resources: If I can access a document, can I access its comments?\n  What if the document belongs to someone else?\n\n□ For tenant\u002Forg resources: Can User in Org A access Org B's data by changing\n  the org_id in the URL?\n```\n\n---\n\n## Phase 4: Trace Specific Flows\n\nPick a concrete endpoint and trace it completely.\n\n### Example Investigation\n\n```\nEndpoint: GET \u002Fapi\u002Fdocuments\u002F{pk}\u002F\n\n1. Find the view handling this URL\n   → DocumentViewSet.retrieve() in api\u002Fviews.py\n\n2. Check what DocumentViewSet inherits from\n   → class DocumentViewSet(viewsets.ModelViewSet)\n   → No custom base class with authorization\n\n3. Check permission_classes\n   → permission_classes = [IsAuthenticated]\n   → Only checks login, not ownership\n\n4. Check get_queryset()\n   → def get_queryset(self):\n   →     return Document.objects.all()\n   → Returns ALL documents!\n\n5. Check for has_object_permission()\n   → Not implemented\n\n6. Check retrieve() method\n   → Uses default, which calls get_object()\n   → get_object() uses get_queryset(), which returns all\n\n7. Conclusion: IDOR - Any authenticated user can access any document\n```\n\n### What to look for when tracing\n\n```\nPotential gap indicators (investigate further, don't auto-flag):\n- get_queryset() returns .all() or filters without user\n- Direct Model.objects.get(pk=pk) without ownership in query\n- ID comes from request body for sensitive operations\n- Permission class checks auth but not ownership\n- No has_object_permission() and queryset isn't scoped\n\nLikely safe patterns (but verify the implementation):\n- get_queryset() filters by request.user or user's org\n- Custom permission class with has_object_permission()\n- Base class that enforces scoping\n- Manager that auto-filters\n```\n\n---\n\n## Phase 5: Report Findings\n\nOnly report issues you've confirmed through investigation.\n\n### Confidence Levels\n\n| Level | Meaning | Action |\n|-------|---------|--------|\n| **HIGH** | Traced the flow, confirmed no check exists | Report with evidence |\n| **MEDIUM** | Check may exist but couldn't confirm | Note for manual verification |\n| **LOW** | Theoretical, likely mitigated | Do not report |\n\n### Suggested Fixes Must Enforce, Not Document\n\n**Bad fix**: Adding a comment saying \"caller must validate permissions\"\n**Good fix**: Adding code that actually validates permissions\n\nA comment or docstring does not enforce authorization. Your suggested fix must include actual code that:\n- Validates the user has permission before proceeding\n- Raises an exception or returns an error if unauthorized\n- Makes unauthorized access impossible, not just discouraged\n\nExample of a BAD fix suggestion:\n```python\ndef get_resource(resource_id):\n    # IMPORTANT: Caller must ensure user has access to this resource\n    return Resource.objects.get(pk=resource_id)\n```\n\nExample of a GOOD fix suggestion:\n```python\ndef get_resource(resource_id, user):\n    resource = Resource.objects.get(pk=resource_id)\n    if resource.owner_id != user.id:\n        raise PermissionDenied(\"Access denied\")\n    return resource\n```\n\nIf you can't determine the right enforcement mechanism, say so - but never suggest documentation as the fix.\n\n### Report Format\n\n```markdown\n## Access Control Review: [Component]\n\n### Authorization Model\n[Brief description of how this codebase handles authorization]\n\n### Findings\n\n#### [IDOR-001] [Title] (Severity: High\u002FMedium)\n- **Location**: `path\u002Fto\u002Ffile.py:123`\n- **Confidence**: High - confirmed through code tracing\n- **The Question**: Can User A access User B's documents?\n- **Investigation**:\n  1. Traced GET \u002Fapi\u002Fdocuments\u002F{pk}\u002F to DocumentViewSet\n  2. Checked get_queryset() - returns Document.objects.all()\n  3. Checked permission_classes - only IsAuthenticated\n  4. Checked for has_object_permission() - not implemented\n  5. Verified no relevant middleware or base class checks\n- **Evidence**: [Code snippet showing the gap]\n- **Impact**: Any authenticated user can read any document by ID\n- **Suggested Fix**: [Code that enforces authorization - NOT a comment]\n\n### Needs Manual Verification\n[Issues where authorization exists but couldn't confirm effectiveness]\n\n### Areas Not Reviewed\n[Endpoints or flows not covered in this review]\n```\n\n---\n\n## Common Django Authorization Patterns\n\nThese are patterns you might find - not a checklist to match against.\n\n### Query Scoping\n```python\n# Scoped to user\nDocument.objects.filter(owner=request.user)\n\n# Scoped to organization\nDocument.objects.filter(organization=request.user.organization)\n\n# Using a custom manager\nDocument.objects.for_user(request.user)  # Investigate what this does\n```\n\n### Permission Enforcement\n```python\n# DRF permission classes\npermission_classes = [IsAuthenticated, IsOwner]\n\n# Custom has_object_permission\ndef has_object_permission(self, request, view, obj):\n    return obj.owner == request.user\n\n# Django decorators\n@permission_required('app.view_document')\n\n# Manual checks\nif document.owner != request.user:\n    raise PermissionDenied()\n```\n\n### Ownership Assignment\n```python\n# Server-side (safe)\ndef perform_create(self, serializer):\n    serializer.save(owner=self.request.user)\n\n# From request (investigate)\nserializer.save(**request.data)  # Does request.data include owner?\n```\n\n---\n\n## Investigation Checklist\n\nUse this to guide your review, not as a pass\u002Ffail checklist:\n\n```\n□ I understand how authorization is typically implemented in this codebase\n□ I've identified the ownership model (user, org, tenant, etc.)\n□ I've mapped the key endpoints that handle user data\n□ For each sensitive endpoint, I've traced the flow and asked:\n  - Where does the ID come from?\n  - Where is data fetched?\n  - What checks exist between input and data access?\n□ I've verified my findings by checking parent classes and middleware\n□ I've only reported issues I've confirmed through investigation\n```\n\n## Limitations\n- Use this skill only when the task clearly matches the scope described above.\n- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.\n- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.\n","","imported","https:\u002F\u002Fgithub.com\u002Fsickn33\u002Fantigravity-awesome-skills","user_system_seed","SkillOPIC",true,89,1378,"2026-05-16 13:15:31",{"id":8,"name":21,"slug":22,"icon":23,"description":24,"sort":25,"createdAt":26},"编程开发","coding","mdi-code-braces","代码生成、调试、审查，提升开发效率",2,"2026-05-16 12:53:40",{"id":7,"name":28,"slug":29,"icon":30,"description":31,"moduleId":8,"sort":25,"skillCount":32,"createdAt":26},"后端开发","backend","mdi-server","API、数据库、服务端架构",296,[34],{"id":35,"skillId":4,"version":36,"fileName":37,"fileSize":38,"filePath":39,"fileHash":40,"manifest":41,"createdAt":19},"0df20c44-646c-4e34-a332-0d165eaee044","1.0.0","django-access-review.zip",4417,"uploads\u002Fskills\u002F6db19e1a-2645-4c27-a00c-d69371672194\u002Fdjango-access-review.zip","24ee662b6945a6340d67b6692c6cdb599d1d87dd3c8239141f46d109497f25ad","[{\"path\":\"SKILL.md\",\"isDirectory\":false,\"size\":10941}]",{"code":43,"message":44,"data":45},200,"success",{"items":46,"stats":47,"page":50},[],{"averageRating":48,"totalRatings":48,"ratingCounts":49},0,[48,48,48,48,48],{"limit":51,"offset":48,"hasMore":52,"nextOffset":51,"ratedOnly":16},15,false]