What you will be able to do
- Explain why app executables run with owner's rights by default, and what that means for consumers
- Create a stored procedure with EXECUTE AS RESTRICTED CALLER and declare restricted_callers_rights in the manifest
- Run the consumer-side GRANT CALLER workflow at schema, database and account scope
- State the limitations of restricted caller's rights and choose the right access mechanism
- Apply the code security requirements and the framework's intellectual property protections
1.Owner's rights versus restricted caller's rights
A Native App has two kinds of executables: stored procedures owned by the app, and services in apps with containers. Each one runs under either owner's rights or restricted caller's rights. If you create a procedure without an EXECUTE AS clause, it uses owner's rights. It then runs with the app's own privileges, and consumers can call it when an application role gives them access. Whatever the app is allowed to do, the procedure can do.
Checkpoint 1 of 7· Check yourself
A setup script creates a stored procedure with no EXECUTE AS clause. How does it run when a consumer calls it?
Owner's rights is the default for executables in an app, and the owner is the app itself.
“By default, executables within an app use owner’s rights”Source: docs.snowflake.com
Restricted caller's rights (RCR) run the executable with the caller's rights, but only with the subset of the caller's privileges that a consumer administrator has explicitly allowed with GRANT CALLER. Plain, unrestricted caller's rights are not supported, which keeps app executables secure. The provider opts in by using the EXECUTE AS RESTRICTED CALLER clause, and Snowflake recommends also declaring restricted_callers_rights in the manifest. The manifest entry is optional. When it is present with enabled: true, Snowsight shows a Restricted caller’s rights section in the listing.
restricted_callers_rights:
enabled: true
description: This app includes stored procedure that uses restricted caller's rights.Checkpoint 2 of 7· Fill the gap
Complete the setup-script procedure so it runs with restricted caller's rights.
CREATE OR REPLACE PROCEDURE CORE.HELLO()
RETURNS STRING
LANGUAGE SQL
EXECUTE AS ? CALLER
AS
BEGIN
RETURN 'Hello Snowflake!';
END;The clause is EXECUTE AS RESTRICTED CALLER. Owner's rights needs no clause because it is the default.
Source: docs.snowflake.comSources1
2.The consumer GRANT CALLER workflow
An RCR executable can do nothing with the caller's privileges until the consumer issues caller grants. To grant them, the consumer must use ACCOUNTADMIN or a role that holds MANAGE CALLER GRANTS. Start with the app's listing, which should say whether the app has RCR executables, and then grant what it asks for. Snowflake recommends granting at container level (schema, database or account) rather than on individual objects. A container-level grant only covers the container itself. CALLER USAGE on a schema gives USAGE on that schema and nothing on the objects inside it. To reach the objects, add INHERITED grants such as GRANT INHERITED CALLER USAGE ON ALL FUNCTIONS IN SCHEMA. For a service in an app with containers, the app is the service owner role, so the consumer names it with TO APPLICATION.
GRANT CALLER USAGE ON DATABASE consumer_db TO APPLICATION hello_snowflake_app;Account-level caller grants allow account-level operations. An executable can be configured to use CREATE DATABASE, EXECUTE ALERT, EXECUTE MANAGED TASK, EXECUTE TASK, READ SESSION and VIEW LINEAGE, for example GRANT CALLER CREATE DATABASE ON ACCOUNT TO my_app;. Consumers should be cautious with these grants. Snowsight can also grant caller grants, but only when the provider has configured the app to show the RCR UI. In Snowsight, pick the narrowest Access scope that works. Snowsight adds USAGE automatically on the objects you select, applies the same privileges to future objects of the selected type, and shows the GRANT CALLER SQL it will run. Revoking caller grants, granting on one specific table, and granting account-level caller's rights all have to be done in SQL.
Checkpoint 3 of 7· Check yourself
A consumer runs GRANT CALLER USAGE ON SCHEMA db1.sch1 TO APPLICATION my_app. The app's RCR procedure still can't query tables in that schema. Why?
Schema-level caller grants cover the schema only. The consumer also needs an INHERITED CALLER SELECT ON ALL TABLES IN SCHEMA grant, along with USAGE on the database.
“Grants caller rights to the schema, but does not grant any rights to objects in the schema.”Source: docs.snowflake.com
Checkpoint 4 of 7· Exam question
A provider is establishing the privilege-granting workflow a consumer will follow after installing a Native App with several requested global privileges and one required reference. Which statements correctly describe that workflow? (Select all that apply)(Select 3)
Correct answers: A, B, D — The consumer can review each requested privilege's description before deciding whether to grant it; A required reference with required_at_setup true must be bound before installation can complete; The consumer can apply a feature policy to further constrain the app even after granting requested privileges
- A. Each privilege entry in the manifest carries a description specifically so the consumer can evaluate the request before deciding to grant it.
- B. When a reference is marked required_at_setup, the consumer must supply the bound object as part of installation, or the installation cannot proceed.
- C. Automatic usability without consumer action only applies under manifest_version 2's automated granting; under manifest_version 1 the consumer must issue explicit GRANT statements, so privileges are not universally auto-usable regardless of manifest version.
- D. Feature policies can be layered on top of granted privileges to further restrict what the app is allowed to do, giving the consumer an additional governance lever.
- E. Granted privileges can be revoked by the consumer at any time using standard REVOKE statements; grants are not permanent or irreversible.
3.Limitations of restricted caller's rights, and choosing a mechanism
RCR has firm limits inside an app. Unrestricted caller's rights aren't supported. Persistent reference functions aren't supported, and neither are relative paths to objects on a stage. An RCR executable can't access the app's internal objects. Owner's-rights executables in the app can call RCR executables only if the app also owns those RCR executables. An app's owner's-rights procedure therefore can't call a consumer's RCR procedure.
Because of these limits, RCR is one option among several. The provider documentation maps each access need to a mechanism.
| Access required | How to get access |
|---|---|
| Data or functions owned by the app | Owner's rights (default); no consumer request needed |
| Specific tables, views, or functions in the consumer account | Request references from the consumer |
| Tables, views, functions, and row policies owned by another user or role | Restricted caller's rights |
| Broad access to consumer-owned databases | Database role grants |
| Queries combining consumer and provider data | References and owner's rights together |
| Account-level operations such as creating databases or executing tasks | Restricted caller's rights |
Checkpoint 5 of 7· Match them up
Match each access need to the mechanism the documentation recommends.
Tap a term, then the definition that fits it.
Owner's rights covers app-owned objects, references cover specific named objects, RCR covers objects owned by other roles and account-level operations, and database role grants cover broad database access.
“Use restricted caller’s rights, which allow the consumer to enable access to these objects.”Source: docs.snowflake.com
Sources1
4.Code security requirements and intellectual property protection
Execution rights are also how a provider protects intellectual property. With owner's rights, an executable can read data in the provider account and show results to the consumer, while the consumer never gets direct access to that data. The framework adds its own safeguards. For views the app owns, information about the base table is redacted. Context functions that could reveal information about objects inside the app are blocked. Providers should be careful about granting MONITOR or OPERATE on dynamic tables to an application role, because those privileges let consumers view metadata that might expose how the app is built.
Hiding the code itself is not one of the options. Apps that fall under automated security review must follow code requirements. The app must not load or execute code from outside the application package, except Snowflake-provided libraries. All app code must be un-obfuscated and human-readable, and that includes minified JavaScript. If you ship minified JavaScript, you must include a source map that recovers the original code. Dependencies with critical or high CVEs must be updated to a secure version, if one is available.
Checkpoint 6 of 7· Exam question
A provider is designing a cross-account reference so a Native App can process a consumer's table that will be chosen after installation, and wants the binding process itself to be secure. Which design choices support that goal? (Select all that apply)(Select 4)
Correct answers: A, B, C, E — Setting required_at_setup to false so the consumer is not forced to expose an object before they are ready to select one; Declaring object_type so only a compatible kind of object can be bound to the reference; Requesting the minimum privileges list needed on the bound object rather than defaulting to broader access; Using register_callback to run provider validation logic immediately after the consumer selects an object
- A. Letting the reference be optional at setup gives the consumer time to choose the right object deliberately instead of being forced into a hasty binding during installation.
- B. Typing the reference to a specific object kind prevents the consumer from accidentally, or an attacker from deliberately, binding an incompatible or overly broad object.
- C. Requesting only the minimum privileges needed on the bound object limits what the app can do even if the wrong object is bound, reducing the impact of a binding mistake.
- D. Omitting the description removes exactly the context a consumer needs to make an informed, secure choice about what to bind, which works against secure reference design rather than supporting it.
- E. Running validation logic right after binding lets the provider check the selected object meets expectations before the app relies on it, closing a window where a bad binding could go unnoticed.
Checkpoint 7 of 7· Check yourself
A provider wants to stop consumers from reverse-engineering proprietary logic. Which approach is consistent with the Native App security requirements?
Obfuscation, minifying without a source map, and loading external code are all prohibited. Protection comes from owner's rights, the framework's redaction, and careful choice of which privileges application roles receive.
“All app code must be un-obfuscated, meaning that the code must be human readable.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Obfuscating stored procedure code, or fetching it from an external server, is an acceptable way to protect a provider's intellectual property.Why is that wrong?
App code must be human-readable, and no code may be loaded from outside the application package except Snowflake-provided libraries. IP protection comes from owner's rights and the framework's redaction.
Covered in Code security requirements and intellectual property protection
2.A restricted caller's rights procedure can read both the caller's granted objects and the app's own internal tables.Why is that wrong?
RCR executables can't access the app's internal objects. Logic that touches app-owned data has to run with owner's rights.
Covered in Limitations of restricted caller's rights, and choosing a mechanism
3.Any consumer role with OWNERSHIP of the app can issue GRANT CALLER to it.Why is that wrong?
Caller grants require ACCOUNTADMIN or a role that holds MANAGE CALLER GRANTS.
Covered in The consumer GRANT CALLER workflow
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“cannot run with a specific privilege unless an administrator in the consumer account explicitly allows it by using the GRANT CALLER command.”
↩︎ Owner's rights versus restricted caller's rights“if it is present and enabled is set to true, Snowsight includes a section named Restricted caller’s rights in the app’s listing.”
↩︎ Owner's rights versus restricted caller's rights“When granting caller grants, a consumer specifies the app by using the TO APPLICATION clause”
↩︎ The consumer GRANT CALLER workflow“Relative paths to objects on a stage are not supported.”
↩︎ Limitations of restricted caller's rights, and choosing a mechanism“an app’s stored procedure with owner’s rights cannot call a consumer’s stored procedure with restricted caller’s rights.”
↩︎ Limitations of restricted caller's rights, and choosing a mechanism“However, they do not allow the consumer to access the data directly.”
↩︎ Code security requirements and intellectual property protection“Restricted caller’s rights executables cannot access the app’s internal objects.”
↩︎ Exam trap 2“By default, executables within an app use owner’s rights”
↩︎ Checkpoint“Snowflake Native Apps do not support unrestricted caller’s rights.”
↩︎ Prediction“Use restricted caller’s rights, which allow the consumer to enable access to these objects.”
↩︎ Checkpoint - 2.https://docs.snowflake.com/en/developer-guide/native-apps/ui-consumer-restricted-callers-rightsOfficial docs
“Snowflake recommends that consumers grant caller grants at a container level and not on specific objects in their account.”
↩︎ The consumer GRANT CALLER workflow“You can only grant caller grants from Snowsight if the provider has configured the app to display the restricted caller’s rights UI.”
↩︎ The consumer GRANT CALLER workflow“you must use the ACCOUNTADMIN role or use a role that has the MANAGE CALLER GRANTS privilege.”
↩︎ Exam trap 3“Grants caller rights to the schema, but does not grant any rights to objects in the schema.”
↩︎ Checkpoint - 3.
“Additionally, for views owned by the app, information about the base table is redacted.”
↩︎ Code security requirements and intellectual property protection“These privileges allow the consumer to view a dynamic table’s metadata, which might expose the implementation details of the app.”
↩︎ Code security requirements and intellectual property protection - 4.
“it must include a corresponding source map file that can be used to recover the un-minified code.”
↩︎ Code security requirements and intellectual property protection“Your app must not load or execute any code from outside the application package except Snowflake-provided libraries.”
↩︎ Exam trap 1“All app code must be un-obfuscated, meaning that the code must be human readable.”
↩︎ Checkpoint