We are working in an enterprise environment and have chosen Drupal 9 (will be upgraded to 10 once its available) to deliver the following features:
- CMS
- Minimal basic features such as User Management (via external IDAM using Drupal plugins).
Immediate plan is to install Drupal in single web server. However, architecturally (logical architecture), we have following two choices:
1. Go with Monolithic default Architecture - our current requirements are very minimal with hardly 2-3 pages and user management activities. This is the preferred approach for a quick delivery.
2. Go with Decoupled Architecture (though front-end and API Layer both will be in Drupal initially) - This could be our target state. For now, even if we go with decoupled, the frontend and API layer are still planned to be in the same physical server. But given the timelines, we might go with Monolithic.
However, we want to understand the following:
- If we choose Decoupled architecture but deploy both Frontend and API layer in the same physical server, is that still better than Monolithic architecture from "security point of view". Isn't that as good as Monolithic Architecture if there is no physical separation b/w Frontend and API layer.
- In general, does Monolithic architecture has any security concerns (other than if the Web server is compromised).
- Is there any possibility of the Roles management in monolithic architecture to get compromised (unless web server itself is compromised) when compared to the Decoupled Arch. During pen testing, can a tester view/modify the roles and portrait to be a different authority. From our understanding, if say an admin role is assigned to user 1 with excess privileges but say user 2 has limited privileges, there is no way that the user's role will be compromised and user 2 cannot portrait to be an admin by sniffing or inspecting the data elements.
Highly appreciate your response.
Comments
Drupal has an excellent front
Drupal has an excellent front-end on it's own, that is built to work with Drupal. The advantages to using Drupal's front-end (Twig theming layer, and Drupal's JavaScript API) are that they are built to work with Drupal specifically, and don't require special knowledge to integrate with Drupal. They do however require someone to be familiar with Drupal's front-end theming system. Headless architecture such as React will allow for React developers who know nothing about Drupal to work on the front-end, however a developer who knows how to expose Drupal to headless front-ends is required, so either way a specialist skill set is required. I personally feel that using Drupal headless requires a lot of additional development to match functionality already provided by using Drupal's front-end. As such, I personally am for the monolithic approach, when it comes to the front-end of Drupal.
You will have more security issues between a headless architecture and Drupal, than using a monolithic Drupal-only architecture. And Twig has been built so that if the user follows best practices, everything is escaped for additional security.
Same as with the last question, there is more of a possibility with headless architecture. Both however will require a knowledgeable Drupal developer who follows best practices and uses all the relevant APIs to ensure security. And if security is of particular importance, penetration tests should always be performed. A skilled Drupal developer will be able to respond to any issues raised in a penetration test.
Contact me to contract me for D7 -> D10/11 migrations.
Security of Drupal in Monolithic Architecture
Thanks @jaypan, this answer is very precise and elaborate enough. Yes, we have planned the Pen testing at later states but want to mitigate the risk upfront and ensure that we are choosing the right architecture. Also, we are hiring Sr. Drupal developers who will ensure complying with the best practices.
Just one clarification,
"You will have more security issues between a headless architecture and Drupal ....
Would you be able to provide a specific example to support the above statement?
"You will have more security
I should have said "will have the potential for more...".
Basically, Drupal has a flow for building web pages. Processing happens from core -> modules -> theme. The architecture of Drupal built on a component-based level, whereby core and modules will define components, modules will alter those components, and themes display them. Default templates are provided by the core or theme that defines the component, and themes can extend or override the templates to display the output according to that theme. All of these are tied together with Drupal APIs, that have a heavy focus on security (when best practices are followed, and relevant APIs are used).
When using Drupal headless, with some other framework to interact with Drupal, the framework itself determines what components are necessary, and request the data to display, through Drupal APIs. Often custom API endpoints must be created to provide data, and this is where I feel there is a higher risk of security issues, as testing on this endpoint data happens only internally (and penetration tests), whereas using Drupal APIs with best practices, are methods that have been looked over by thousands of eyes, with appropriate security applied to ensure data is kept safe. As such, I feel there is more risk in headless architecture than in monolithic Drupal.
I'd be interested in to hear the thoughts of others too though. While I am a front and back end specialist in Drupal, I've only built the Drupal architecture for other developers who have built a headless front-end, I've never built the headless front-end myself.
Contact me to contract me for D7 -> D10/11 migrations.
I've just re-read your post,
I've just re-read your post, and noticed something I missed:
Front-end architecture is written in JavaScript. The front-end architecture is loaded into a browser on the initial request, then subsequent requests are made using HTTP requests in the background, updating the HTML as necessary. Having the front-end architecture load from the same server as the data is served from makes for easier to manage security than requesting data from a different domain. A headless architecture can definitely retrieve data from the same domain it is served from, and while I haven't confirmed it, I expect that the data source for a headless architecture can be configured to be a separate domain. A monolithic installation on the other hand, by architecture requests data from the same domain. So the comparison for this isn't between monolithic and headless, as both are able to provide same-domain access to data, which is more secure.
Contact me to contract me for D7 -> D10/11 migrations.
Headless architecture
Thanks for the response.
With headless architecture (regardless of technology), the recommendation is to keep separate servers. While front-end runs in web-server, the API layer is recommended to run in app server. They need not to be in separate domains. Ideally they should connect over the VPN/dedicated n/w. Only front-end should be available to the public while securing the app server. Other infrastructure security components could be load balancer, CDN, Cache etc. in front of Front-end, thereby completely separating front-end from backend services.
Only doubts we had were around Roles/user management in Drupal, but appears its secured enough and monolithic is recommended (based on the details provided by you - as long as the recommended guidelines are followed).