OpenID Connect Provider Security Headers

When implementing OpenID Connect (OIDC), ensuring secure communication is critical. HTTP headers is often overlooked but play a significant role in protecting data and mitigating security risks. In this article, we will explore some of the essential security headers that you should know.

Because OpenID Connect Provider implementation is not so different from a regular web application, you can also read our article on Essential Security Headers for Web Applications.

Let's now focus on the security headers that are essential when implementing OpenID Connect.

Do you really need iframes?

If you are using OpenID Connect for SPA, you might use iframes to handle silent authentication. However, if you are not using iframes, you can add the X-Frame-Options header to prevent clickjacking attacks on your provider. This header restricts how your web page can be embedded in an iframe and helps protect your application from clickjacking attacks.

Cross-Origin Resource Sharing (CORS)

When implementing OpenID Connect, you might need to make cross-origin requests to the authorization server. To control which resources on your server can be accessed by other domains, you can set the Cross-Origin Resource Sharing (CORS) header. By defining the origins that are allowed to make cross-origin requests to your server, you can prevent cross-origin attacks and protect sensitive data from unauthorized domains.

Except if you are provider a public OpenID Connect Provider, you know the origins that are allowed to make requests to your server. You can set the Access-Control-Allow-Origin header to specify the origins that are allowed to access your server.

Check your cache

When implementing OpenID Connect, you should pay attention to caching sensitive data. The Cache-Control header allows you to control how the browser caches resources on your web page. By setting the Cache-Control header, you can specify whether the browser or intermediate proxies should cache resources, how long they should be cached, and whether they can be stored in shared caches.

Sometimes, because there are intermediates proxies or CDN in front of the OpenID Connect Provider, you should ensure that those components are taking into account the Cache-Control header you are setting. For various reasons (most of the time lack of configuration or lazy configuration), those components might not respect the Cache-Control header you are setting and cache a lot of things to improve performance. However, caching some OP endpoints will lead to security issues and bad behavior. An example would be caching the userinfo endpoint, which contains user information.

OpenID Connect Provider Cookies

When implementing OpenID Connect, the provider might use cookies to store session information or tokens. You should ensure that the cookies are secure and have the appropriate attributes set. For example, you can set the Secure attribute to ensure that the cookie is only sent over HTTPS connections. You can also set the HttpOnly attribute to prevent client-side scripts from accessing the cookie.

Avoid sharing those cookies with other applications by setting the SameSite attribute to Strict or Lax. This will prevent the cookie from being sent in cross-site requests, reducing the risk of cross-site request forgery (CSRF) attacks.

If it is not the case, you should host your OpenID Connect Provider on a different subdomain than your application to avoid sharing cookies between the two applications. This will reduce the number of attacks vectors. OP are usually a critical part well secured and well monitored, but you can have on the same domain a unmaintained application that could be a security issue which will be more easily exploitable if it can access the OP cookies.