Each custom query has its own security rules. They decide whether a visitor, a signed-in user or an admin may run it.
A query always runs on behalf of someone, and its security rules are checked against that person.
Public
A visitor who is not signed in, for example on a public page.
Authenticated user
A signed-in user of your site.
SysAdmin
An administrator. Admins always pass query security.
System
A function started by an event trigger or a schedule. It passes query security like an admin.
1
Open the Security tab
Go to Database, then Custom Queries, click Edit Query and open Security.
2
Choose Allowed Roles
Pick any of SysAdmin, Authenticated User and Public (Unauthenticated).
3
Add tags if needed
With Authenticated User selected, Required User Tags (Optional) appears. Pick tags to limit the query to users who have at least one of them.
4
Save
Click Save Security Rules.
Saving replaces the query's previous security rules.
The rules are checked every time the query runs, inside whichever function runs it.
With no role selected, there is no role restriction: anyone who can run the function can run the query.
With roles selected, only those roles may run it. Admins and trigger runs always pass.
With required user tags, a signed-in user needs at least one of the chosen tags.
If the check fails, the query does not run and the function fails.
Give Public only to read queries over data that is truly public.
Never give Public to an INSERT or UPDATE query unless you want anyone to be able to write rows.
If a query is only used by event triggers or schedules, allow SysAdmin only. Triggers still run it.
Also set who can run the function itself. See Functions for the Who can run this function setting.
Deactivating a query or its table does not block a function from running it. Security rules are the way to control access.
