Data API Builder(DAB)数据权限安全疑问及解决方案咨询

你的担忧完全合理 #

直接让前端通过User ID过滤Addresses表的方式确实存在风险：黑客可以篡改请求参数，要么遍历自增ID获取其他用户数据，要么直接移除过滤条件窃取全表信息，完全绕开前端的逻辑限制。

解决方案 #

1. 数据库行级安全（RLS）+ DAB身份声明映射 #

这是最可靠的底层防护手段，在数据库层面直接限制用户只能访问自己的数据，即使DAB或前端出现漏洞，数据库也会拦截非法访问：

• 在数据库中为Addresses表创建RLS安全策略，例如SQL Server：

  CREATE SECURITY POLICY AddressesFilterPolicy
  ON Addresses
  ADD FILTER PREDICATE (User = SESSION_CONTEXT(N'UserId'))
  WITH (STATE = ON);
  

• 在DAB的配置文件dab-config.json中，配置身份声明映射，将JWT令牌中的用户标识（比如sub或自定义userId claim）注入到数据库会话上下文：

  "entities": {
    "Addresses": {
      "source": "Addresses",
      "permissions": [
        {
          "role": "authenticated",
          "actions": ["read"]
        }
      ],
      "claims-mapping": {
        "UserId": "sub"
      }
    }
  }
  

  这样DAB会自动将当前认证用户的ID传入数据库，RLS策略会自动过滤出该用户的地址数据，前端无需传递User ID，也无法篡改过滤条件。

2. DAB实体自动过滤规则 #

如果不想依赖数据库RLS，可以直接在DAB配置中为实体添加强制过滤条件，确保所有查询都会自动带上用户身份过滤：

"entities": {
  "Addresses": {
    "source": "Addresses",
    "permissions": [
      {
        "role": "authenticated",
        "actions": ["read"],
        "filter": "User eq @claims.sub"
      }
    ]
  }
}

这个配置会让DAB在处理所有针对Addresses的读请求时，自动追加User = 当前用户ID的过滤条件，前端无法通过修改请求绕过。

3. GUID与存储过程的补充防护 #

• GUID替代自增ID：将User列改为GUID类型，确实能大幅降低黑客通过递增ID遍历数据的风险，但这只是防御的补充，不能替代权限控制，因为黑客仍可能通过其他方式获取合法GUID进行访问。
• 暴露存储过程给DAB：可以将查询逻辑封装在存储过程中，存储过程内部从会话上下文获取当前用户ID，仅返回该用户的地址数据，然后在DAB中配置调用该存储过程：

  "entities": {
    "UserAddresses": {
      "source": "GetUserAddresses",
      "source-type": "stored-procedure",
      "permissions": [
        {
          "role": "authenticated",
          "actions": ["read"]
        }
      ]
    }
  }
  

  这种方式下，前端只能调用存储过程，无法直接查询Addresses表，进一步缩小了攻击面。

总结 #

你的安全担忧完全正确，核心解决方案是通过数据库RLS或DAB自动过滤规则实现强制的用户数据隔离，GUID和存储过程可以作为额外的安全增强手段，多层防护确保数据访问的安全性。

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