DRF框架下URL直接暴露条目标识ID的安全风险问题

核心结论先行：直接把数据库条目标识作为路径参数放在URL里本身不构成本质安全隐患，真正的风险来自配套的鉴权、权限校验逻辑缺失，和ID是否出现在URL路径没有直接因果关系。

为什么ID出现在URL本身不是风险 #

• 这是RESTful API设计的标准实践：绝大多数成熟商用服务的接口都会把资源标识直接放在路径中，用来精准定位要操作的具体对象，这种设计本身经过了行业长期验证，不存在“把ID放URL就等于开了后门”的问题。
• 很多人提到的“暴露自增ID的风险”，本质上指向的是*IDOR（不安全的直接对象引用）*漏洞——这个漏洞的核心成因从来不是“用户能看到ID”，而是系统拿到用户传入的资源标识后，没有校验当前用户对该资源的操作权限，就直接执行了写操作，哪怕你把ID藏在请求体、请求头里，没有权限校验的话一样会被攻破。

结合你当前代码的实际风险点梳理 #

• 你现在的代码把authentication_classes和permission_classes都设为空列表，相当于完全关闭了身份验证和权限校验流程，这个状态下不管用什么方式传递资源标识，只要攻击者猜到接口路径，就能传入任意ID修改全表数据，这和ID是否暴露在URL里无关。
• 就算后续你补齐了鉴权和权限配置，如果get_queryset的逻辑没有和当前登录用户的身份绑定，依然会出现跨用户越权操作的问题：比如现在的查询逻辑只按ID过滤，等加上登录校验后，如果不补上资源归属的过滤条件，用户A只要拿到用户B的活动ID，就能直接修改B的活动数据，这才是需要重点防控的核心问题。

常见认知误区澄清 #

• 不少开发者会认为“把自增ID换成UUID、或者把ID藏在加密参数/请求体里更安全”，本质上这属于隐式安全的思路：靠攻击者猜不到ID来挡攻击，一旦ID生成规则被逆向、或者接口泄露了全量资源的ID列表，这类防线会直接失效。
• 真正可靠的防护逻辑从来不是“不让用户看到ID”，而是无论用户传入什么ID，系统都要在查询资源时就完成权限匹配，确保用户只能操作自己被授权范围内的对象，根本接触不到无权限的资源数据。

后续落地参考建议 #

• 配置完鉴权和权限类后，一定要在get_queryset的过滤条件中绑定资源的归属关系，从查询根源上隔离无权限的资源，示例代码：

def get_queryset(self):
    # 强制绑定当前登录用户的资源归属，从根源上避免跨用户越权
    return Activities.objects.filter(
        id=self.kwargs['id'],
        user=self.request.user
    )

• 如果确实担心自增ID被批量枚举带来的爬取风险，可以考虑将模型主键替换为UUID字段降低枚举效率，但这只是缩小攻击面的辅助手段，完全不能替代权限校验本身。

内容的提问来源于stack exchange，提问作者Mislav