When you switch your Drupal site to HTTPS whether via Apache, NGINX you expect Drupal to recognise it’s running securely. But then you notice something off:<\/p>\n
On the browser side, it looks secure. But Drupal doesn\u2019t agree. Let\u2019s break down why, what it causes, and how to fix it.<\/p>\n
Drupal determines whether a request is secure by inspecting $_SERVER variables like:<\/p>\n
But if you\u2019re behind a reverse proxy or load balancer, the HTTPS handshake might happen before the request even reaches your Drupal server. Meaning: your app receives a plain HTTP request and never sees that it was originally HTTPS.<\/p>\n
If the headers aren\u2019t forwarded or handled correctly, Drupal continues to think the request is insecure.<\/p>\n
There are the following ways to overcome such issues.<\/p>\n
Before you write custom code, Drupal actually supports reverse proxy handling natively if you tell it to.<\/p>\n
Add the following lines to your sites\/default\/settings.php file<\/p>\n
$settings['reverse_proxy'] = TRUE;\r\n$settings['reverse_proxy_addresses'] = [$_SERVER['REMOTE_ADDR']];<\/pre>\nHere\u2019s what this does:<\/p>\n
Once this is in place, Drupal will look at headers like X-Forwarded-Proto and properly detect HTTPS.<\/p>\n
But that only works if your proxy is sending the correct headers and Drupal is trusting them.<\/p>\n
If you’re in a more complex environment (e.g. multiple proxies, dynamic IPs, or inconsistent headers), or if the settings.php solution isn’t reliable, here\u2019s another approach:<\/p>\n
You can inject a middleware that explicitly tells Drupal \u201cthis request is secure\u201d based on your own conditions (like environment or headers). This gives you full control. I have created a custom module my_module <\/strong>in the custom module folder.<\/p>\n What This Middleware Does<\/strong> Detect whether the site is running in the production environment. If so, force the request to be treated as HTTPS, regardless of how it arrives. File: modules\/custom\/my_module\/src\/StackMiddleware\/MyModuleMiddleware.php<\/p>\n Key Points Explained<\/strong><\/p>\n File: modules\/custom\/my_module\/my_module.services.yml<\/p>\n <\/p>\n <\/p>\n How to Ensure and Test the Middleware<\/strong> 1.\u00a0Confirm the Environment Setting This setting is critical because the middleware only applies its logic when\u00a0env_name\u00a0is set to\u00a0prod.<\/p>\n 2.\u00a0Simulate a Non\u2011HTTPS Request 3.\u00a0Check Server Variables Inside Drupal In production, this should log\u00a0HTTPS value: HTTPS.<\/p>\n 5.\u00a0Browser-Level Validation<\/p>\n If Drupal isn\u2019t recognizing HTTPS, even when your browser shows it\u2019s secure, it\u2019s likely due to how PHP sees the incoming request, especially behind proxies or load balancers.<\/p>\n There are two solid ways to fix this:<\/p>\n The middleware gives you more flexibility and is great for edge cases. But for most people, updating settings.php is enough.<\/p>\n Either way, getting this right prevents redirect loops, mixed content warnings, and misbehaving $request->isSecure() checks.<\/p>\n Hope this saves someone the hours I spent chasing phantom HTTP bugs in an HTTPS world.<\/p>\n Please let us know if you encounter any issues during the integration process, and feel free to reach out in the comments if you have any questions.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Introduction When you switch your Drupal site to HTTPS whether via Apache, NGINX you expect Drupal to recognise it’s running securely. But then you notice something off: Internal links are still rendered as http:\/\/. $request->isSecure() returns false. Redirects start looping or downgrading to HTTP. You see Mixed Content warnings. On the browser side, it looks […]<\/p>\n","protected":false},"author":1501,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":51},"categories":[3602],"tags":[4862,1157,1220,1192],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/72325"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1501"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=72325"}],"version-history":[{"count":11,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/72325\/revisions"}],"predecessor-version":[{"id":74458,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/72325\/revisions\/74458"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=72325"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=72325"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=72325"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nThe purpose of the middleware in our example is straightforward:<\/p>\n
\nForward the updated request for normal Drupal handling.<\/p>\nThe Implementation<\/h3>\n
Step 1: Create a Middleware Class<\/h3>\n
<?php\r\n\r\nnamespace Drupal\\my_module\\StackMiddleware;\r\n\r\nuse Drupal\\Core\\StringTranslation\\StringTranslationTrait;\r\nuse Symfony\\Component\\HttpFoundation\\Request;\r\nuse Symfony\\Component\\HttpFoundation\\Response;\r\nuse Symfony\\Component\\HttpKernel\\HttpKernelInterface;\r\nuse Symfony\\Component\\HttpKernel\\Exception\\AccessDeniedHttpException;\r\nuse Drupal\\Core\\Site\\Settings;\r\n\r\n\/**\r\n* MyModuleMiddleware middleware.\r\n*\/\r\nclass MyModuleMiddleware implements HttpKernelInterface\r\n{\r\n\r\nuse StringTranslationTrait;\r\n\r\n\/**\r\n* The kernel.\r\n*\r\n* @var \\Symfony\\Component\\HttpKernel\\HttpKernelInterface\r\n*\/\r\nprotected $httpKernel;\r\n\r\n\/**\r\n* Constructs the MyModuleMiddleware object.\r\n*\r\n* @param \\Symfony\\Component\\HttpKernel\\HttpKernelInterface $http_kernel\r\n* The decorated kernel.\r\n*\/\r\npublic function __construct(HttpKernelInterface $http_kernel)\r\n{\r\n $this->httpKernel = $http_kernel;\r\n}\r\n\r\n\/**\r\n* {@inheritdoc}\r\n*\/\r\npublic function handle(Request $request, $type = self::MASTER_REQUEST, $catch = true)\r\n{\r\n \/\/ Enforce HTTPS in production.\r\n if (Settings::get('env_name') == 'prod') {\r\n $request->headers->set('x-forwarded-proto', 'https');\r\n $request->server->set('HTTPS', 'HTTPS');\r\n }\r\n return $this->httpKernel->handle($request, $type, $catch);\r\n}\r\n\r\n}\r\n\r\n\r\n<\/pre>\n\n
\nThe class is placed under the module\u2019s\u00a0StackMiddleware\u00a0namespace and imports essential interfaces and classes from both Symfony and Drupal.<\/li>\n
\nBy implementing the Symfony kernel interface, this class integrates seamlessly into the Drupal request lifecycle.<\/li>\n
\nThe middleware stores a reference to the original Drupal kernel ($httpKernel). Once it completes its logic, it passes control back to the kernel, ensuring the application continues normally.<\/li>\n
\nThe environment is determined using\u00a0Settings::get(‘env_name’). This makes the enforcement conditional, ensuring that developers in local or staging environments are not forced into HTTPS unless necessary.<\/li>\n
\n<\/strong>\u00a0 1. x-forwarded-proto is set to https. This header is vital when working behind a reverse proxy, signaling that the request originally came through HTTPS.
\n2. The $_SERVER[‘HTTPS’] variable is explicitly set to HTTPS, ensuring Symfony and Drupal both treat the connection as secure.<\/li>\n<\/ol>\nStep 2: Register the Middleware as a Service<\/h3>\n
services: \r\nmy_module.middleware:\r\nclass: Drupal\\my_module\\StackMiddleware\\MyModuleMiddleware\r\ntags:\r\n- { name: http_middleware, priority: 1000 }<\/pre>\n
\nOnce you have implemented and registered your middleware, it\u2019s important to validate that it behaves as expected. Here are a few steps you can follow to verify its enforcement of HTTPS in production:<\/p>\n
\nEnsure your\u00a0settings.php\u00a0(or\u00a0settings.prod.php\u00a0if you split configs) contains the environment name:<\/p>\n$settings['env_name'] = 'prod';<\/pre>\n
\nFrom your local terminal or using a tool like\u00a0cURL, simulate an HTTP request:<\/p>\ncurl -I http:\/\/yoursite.com<\/pre>\n
\n
\nAdd temporary debugging or use\u00a0\\Drupal::request()->server\u00a0inspector to check if\u00a0HTTPS\u00a0is being set properly:<\/p>\n\\Drupal::logger('debug')->notice('HTTPS value: @https', ['@https' => $_SERVER['HTTPS'] ?? 'not set']);<\/pre>\n\n
Conclusion<\/h2>\n
\n