Enhancing API Security with Configurable Auth Key in Headers

I'm not sure I fully understand this. Could you share more details about the use-case and how the envisioned solution works like?
What API key are you referring to?

The idea is to add an extra layer of security to the Lupus API by requiring an authentication key (API key) to be included in the headers of all requests made to the Drupal backend. This key could be configured either in the environment file (env) or directly through the Lupus config form. This would help restrict access to the API, ensuring that only authorized clients can make requests.

Here’s a more detailed explanation:

Authentication Key: The proposal is to have a configurable API key that must be included in the request headers. This key could be set in the CMS environment file or through the Lupus config form, providing flexibility depending on the setup. This method is similar to approaches used in other systems, like the Rest API module, which allows protection of REST API endpoints.

Security Benefits: Implementing this would add a significant security layer to the API, helping to prevent unauthorized access. This feature would be particularly useful in cases where the API might otherwise be publicly accessible.

Implementation Flexibility: The use of a header-based approach is both simple and effective, allowing for easy integration into existing workflows. It’s a familiar pattern for many developers, which should make adoption straightforward.

While the rest_api_access_token module is just an example of a contrib module that offers protection for REST API endpoints, the concept here is to integrate a similar mechanism directly into Lupus, providing a built-in option for those who want this additional security feature.

I hope this provides a clearer picture of the proposal. Let me know if you have any questions or if further discussion is needed.

First off, thanks for the suggestion. Very interesting!

I wonder why the API needs to be secured though, since when the API is publically available, the rendered pages will show exactly the content of the API. So why protect the API? Without looking into it much, rest_api_access_token seems to protect POST requests only. We atm do not have any POST requests that would need to be protected. That will change with form support, but those will be protected as usual via the form-API and its tokens. Could you elaborate a bit more on why you think the protection is needed?

Now that you explain it, it does make this pointless.