How should security be handled for XM Cloud/Headless with Experience Edge?

Question

In the Sitecore documentation for Experience Edge (used by XM Cloud), it states:

Experience Edge for XM does not enforce security constraints on Sitecore content. You must apply publishing restrictions to avoid publishing content that you do not want to be publicly accessible - Limitations & Restrictions of Experience Edge for XM

In Sitecore MVC, we could add security roles to page items and the pages would only show for logged in users that matched those roles. How can we achieve this in Headless with Experience Edge?

Answer 1

The statement in the Sitecore documentation is somewhat misleading. Publishing your content to Experience Edge does NOT expose that content to the public. The Experience Edge endpoint requires an API Key/secret to get content and that API Key/secret should never be exposed to the public. Do not ever directly call the Experience Edge end point from client-side code, obfuscate this behind an API.

The users and roles in the Sitecore CM, should never be used to provide logins to your delivered website. This has been done many times in the non-headless world, but it is a bad practice and leads to user stores that do not scale well and can make it harder to administer your CM users too.

You should keep your authentication for your CM users separate from your website users.

For headless applications, your head application (Next.js/React/ASP.NET Core etc...) is entirely responsible for securing any part of your website. Each framework has ways of doing this so I will cover principles here vs concrete examples. But in general, you can explicitly secure parts of your website via hard coded methods, or you can use data from the CM to decide how to secure that data.

You should use an auth provider to provide authentication/roles etc.. (e.g. Auth0, (Firebase)[https://firebase.google.com/] etc...) and integrate that with your application.

If you want to control what is/isn't visible to users, you can easily create a field on your page templates to identify who can see that page to your head application. But its up to the head application to obey those rules.

Answer 2

@richard-seal thanks for the useful information. Apart from above some information from one of the Sitecore Slack discussion from you side, which also would be helpful for Sitecore Community members:

Use of Sitecore CMS User’s to manage the page access in Sitecore Headless implementation would not be a recommend approach. We shouldn't be using Sitecore for your user store on your delivery application. The Sitecore users are for CM access.

For authentication/authorization use an external authorization provider. If you want security information to be controlled within the CMS on a page level basis, you will need to add fields to your page template, for example, set the roles that can view this page. Do not use the built-in security fields for this. Then read those in your head application, compare to your auth provider and allow/deny access that way.

You can supply meta data that instructs the head application how to secure the content. But the FE application needs to do that part.

Your head application should never be hitting Sitecore or Edge directly from the client side/browser. There should always be some level of server-side processing/rendering that hides away any API Keys/Secrets/Secured content from the browser/user.

Next.js is a full stack framework, it’s not just a front-end framework. React/Angular both have server side only parts to their stack too. When we stop thinking of the head application as a "Front End" thing, it becomes clearer as to where and how you do your logic and security.