360 Secure SkillHub
360 安全技能中心

Authorization

该 Skill 面向授权(非认证)场景,提供 RBAC、ABAC、ReBAC、ACL 等模型选择、角色设计、权限命名、策略评估顺序和常见陷阱的参考规则,并包含实现模式与框架中间件文档;声明不自动访问代码库、不发起网络请求、不存储用户数据。

ivangdavila
ivangdavila
热度 83.00
最近更新 2026-05-11 17:26:18
分类:安全依赖:纯提示词应用场景:代码生成 / 工作流 / 模板

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add authorization
Metadata
name
Authorization
slug
authorization
version
1.0.0
homepage
https://clawic.com/skills/authorization
description
Build secure access control with RBAC, ABAC, permissions, policies, and scope-based authorization.
metadata
{"clawdbot":{"emoji":"🔐","requires":{"bins":[]},"os":["linux","darwin","win32"]}}

When to Use

User needs to control what actions users can perform. Agent handles permission design, role hierarchies, policy evaluation, and access control middleware.

Quick Reference

Topic File
RBAC vs ABAC comparison models.md
Implementation patterns patterns.md
Framework middleware middleware.md

Core Rules

1. Auth ≠ Authorization

  • Authentication: Who you are (login, OAuth, tokens)
  • Authorization: What you can do (permissions, roles, policies)
  • Never mix concerns — auth happens BEFORE authorization

2. Principle of Least Privilege

  • Default deny — explicit grants only
  • Users get minimum permissions for their job
  • Audit permissions periodically (revoke unused)
  • Temporary elevation over permanent grants

3. Choose the Right Model

Model Best For Complexity
ACL Simple resource ownership Low
RBAC Organizational hierarchies Medium
ABAC Dynamic context-based rules High
ReBAC Social graphs, sharing High

Start simple → evolve when needed.

4. Role Design Patterns

  • Roles represent jobs, not permissions
  • Max 3 inheritance levels (admin → manager → user)
  • Avoid role explosion — combine with ABAC for edge cases
  • Document role definitions (what can this role DO?)

5. Permission Naming

resource:action:scope
documents:write:own     ← Can edit own documents
documents:write:team    ← Can edit team documents
documents:delete:all    ← Can delete any document

Consistent naming prevents ambiguity.

6. Policy Evaluation Order

  1. Explicit deny → always wins
  2. Explicit allow → checked second
  3. No match → default deny
  4. Log all denials for debugging

7. Never Hardcode

// ❌ Bad — hardcoded role check
if (user.role === 'admin') { ... }

// ✅ Good — permission check
if (can(user, 'settings:update')) { ... }

Roles change. Permissions are stable.

Common Traps

  • Checking roles instead of permissions → brittle when roles change
  • OR logic in permissions → "can edit OR is admin" creates backdoors
  • Caching permissions too long → stale grants after role changes
  • Frontend-only checks → always verify server-side
  • God roles → split "admin" into specific permission sets
  • Circular inheritance → A inherits B inherits A crashes system

Security & Privacy

Data that stays local:

  • All documentation and patterns are reference material
  • No data collection or external requests

This skill does NOT:

  • Access your codebase automatically
  • Make network requests
  • Store any user data

Feedback

  • If useful: clawhub star authorization
  • Stay updated: clawhub sync