This text is only referring to the CMS UI (Editing Interface) and the public site. So the suggestion is just lock down the CMS UI outside of the public domain to increase security so that only certain people such as the org can access it. If by API you're referring to the Content Delivery API I would expect that to just run of the public website but you could chose to separate it however it really depends what software your connecting the API to. If you're building headless you'll have to have the Content Delivery API on a public server for it to be accessible, if you're using it to connect to another system that doesn't you could chose to run in purely on the CMS UI box.

Hi Scott,

Thank you for answering! And yes, by Api I was referring to the content delivery api.

The only requests allowed to reach the server hosting the CMS UI/Api would be made by the whitelisted frontend server (so no browser ajax requests going straight to the CMS UI/Api server) or by editors within the org using the UI.

Maybe I should have written headless instead of decoupled since the frontend is not connected to episerver (so no Episerver on that server), it just consumes the content delivery api, but I figured enabling on page editing by html attributes would make it decoupled? (I haven't fully grasped the distinction...)

So I guess what I'm wondering is if splitting the CMS UI/Api into a sole purpose ui-server (and removing the UI parts from the would be sole purpose api-server) is to be considered best practice in this scenario from a security point of view?

Yes sure, that helps to understand your questions.

Most of the examples that I've seen use the Content Delivery API as a headless approach and supporting the OPE are client side driven. Such as the demos https://github.com/episerver/musicfestival-vue-template which are vue.js and the react version and documentation for OPE support https://world.optimizely.com/documentation/developer-guides/CMS/editing/on-page-editing-with-client-side-rendering/ . If you say you are consiming it directly from an IP locked web frontend server that's restricted then you are consuming the Content Delivery API from another backend framework such as node.js? If so I'm not sure there's any framework I know of for supporting the on page editing as these are all built for consuming via the client side to a public instance of the Content Delivery API.

Around security however, the best practice around all this is really just around securing the editor interface but these are more a suggestion. For example on the Optimizely Digital Experience platform everything comes from the public WebApp instance and any CMS UI lockdown is instigated by IP and that's on their core recommended platform. 

So when self hosting I'd say the main questions if there is the need for a more security access to the CMS UI needed? There's still IP restrictions for the admin you can setup and forcing strong passwords so unless you feel it's needed I'd say it's not necessary (and as mentioned the DXP doesn't even do it) and also that if your frontend server isn't going to have the Optimizely platform on it then I would keep any frontend server as lean as possible. 

Thanks for the awesome information.

Thanks!

You make some excellent points. Regarding the OPE I actually had not even considered this might become a problem but you're right of course. However, since the editors will always be on a private network I think we should be able to circumvent the issue since the api/cms ui must also be allowed to be reached by said network IP, but I definitely need to get a proof of concept up and running when I'm back at work :-)

Again, thank you for your time and input!