Data API Builder - Azure Static Web Apps

Question

Data API Builder - Azure Static Web Apps

JohnM 25

Trying to understand Data API Builder (DAB) and if its right for my use case.

Based off a simple address book example, there is a table "Addresses" that would have columns:

User (the user of the address book, likely an ID linked from a User table)
Name
Email Address

In a standard web application (front end + back end) to get a list off all addresses belong to the app User, a back end function would take a User ID (de-crypted from the User authentication) and return all address linked to the User.

In the DAB example, the front end will be filtering/querying the address table based on the User ID same as above.

But what is to stop a hacker just incrementing User ID's and extracting all address from the entire table or not even adding the the User ID to the query filter and getting the entire Address table?

The standard web app above has authorization to make sure only the User's Addresses are returned.

Are my assumptions correct?

Are there solutions to fix this?

How do you make sure its only possible to return address linked to the the authorized User only?
Use a GUID for User ID and expose only a Stored Proc to DAB?

1 answer

Your answer

Answer 1

Hello JohnM,

Thank you for submitting your question on Microsoft Q&A.

Without the right authorization and security settings, a frontend app could potentially bypass filters and access all data in the "Addresses" table by altering its requests. Data API Builder (DAB) does not secure your data by default you need to set up authorization rules to avoid this risk.

Solutions to Address This

Securing a DAB application starts with implementing row-level security (RLS). RLS ensures users can only access the data they're allowed to see, regardless of client-side filtering attempts.

Use an Authentication Provider

First, configure an authentication provider in dab-config.json. DAB supports providers like Azure Static Web Apps (EasyAuth), Microsoft Entra ID, or any provider issuing a JWT. This setup allows DAB to identify users and their roles.

Implement Role-Based Authorization

Define roles and permissions for each entity. By default, DAB entities have no permissions, so explicit access must be granted. Assign roles such as authenticated, user, or admin, and ensure the "Addresses" entity is accessible only by the authenticated role.

Apply Row-Level Security

This step is crucial. DAB lets you filter data based on the user's identity, using claims from their access token (like a user ID). For example, in dab-config.json:

"Addresses": {
  "source": {
    "object": "Addresses",
    "type": "table"  },  "permissions": [
    {      "role": "authenticated",
      "actions": [
"read"
],
"policy": {
"read": "@item.User eq @claims.your_user_id_claim"
}
}
]
}

This configuration ensures users can only read rows where their user ID matches the User column. DAB enforces this filter at the database level, making it impossible to bypass via the frontend.

Expose a Stored Procedure

While exposing a stored procedure is an option, it's not required if RLS is in place. If you use a stored procedure with user-specific logic, you can still define execute permissions. Using a GUID for user IDs is a strong security measure, but the real protection comes from DAB's policy enforcement.

For more details, watch the video below on using Data API Builder to expose database objects as APIs.

Data API Builder: How to Create REST and GraphQL Database Endpoints

Share via

Data API Builder - Azure Static Web Apps

1 answer

Your answer