Is there anything I can do to prevent somebody from knowing my site is using Drupal by looking at the source code of the front page? I am referring to people who scan sites using software that detects the software used to run the website to be able to attack it using any known weak point.

If it is not possible to completely hide the fact that the site is using Drupal, is it at least possible to confuse them (e.g., by aliasing the node pages with URLs like http://example.com/servlets/<node-id>.jsp)?

  • 2
    If you don't think the security use case adds up, here's an alternative: commercial confidentiality. A business might not want its competitors to be able to easily figure out what its site is built from. Or, an agency or consultancy might want to keep its competitors in the dark about the current range of tools it is using. Aug 12, 2012 at 1:06

8 Answers 8


This is an old and already answered question, but I recently put some effort into writing up a description of all the things you would need to change:

  • Remove the meta generator for Drupal 7
  • Remove tell-tale-text like CHANGELOG.txt
  • Check the Expires header
  • Walking directories for HTTP 200/404/403 status codes
  • Look for default text messages - tweak all user-facing messages
  • Look at the HTML - default html from core and modules is a telltale sign

Basically: it might technically be possible to hide the fact that your site runs Drupal, but you would spend so much time on it that it's not worth it. You should instead focus on making it secure and on secure operations (e.g. the ability to deploy updates quickly, monitoring logs, etc.).

  • You forgot Drupal JavaScript object that needs to be renamed.
    – Mołot
    Oct 23, 2013 at 8:16
  • @Molot good point. Is that possible? Any pointer on how to do it? My point is that doing it is not worth the time so adding more advice on how to do it is only helpful if it furthers that point. I hope it's really hard to do what you mention :)
    – greggles
    Oct 24, 2013 at 16:26
  • Well, I tested it with mass regex replace on a Drupal directory and it worked... but I don't believe it's really good. And it f*@# up with every module update, of course.
    – Mołot
    Oct 24, 2013 at 19:56
  • Correct. It's not worth your time. Focus on more important things :)
    – greggles
    Oct 26, 2013 at 1:30

You can't hide it completely. Most of what's needed to do it, would require hacking core. The biggest tell, is the Drupal JavaScript variable which is readable from the front page, or any page for that matter.

If you want to improve your sites security by hiding that it's a Drupal site, your effort is better spent on code reviews than it is on trying to hide the fact that the site is made with Drupal.


It's too easy to do!

  • Use a reverse proxy or customize your http daemon to filter the annoying Drupal http header
  • Deny http access to any Drupal default folders
  • Use PHP output buffering to rewrite and obscure your HTML source, remove unnecessary data
  • Use path alias or custom_url_rewrite_in/outbound to make your URLs a mess
  • Change the default 404 error, remove/change update.php
  • Make any other changes if someone finds out

Last but not least, make sure that your site is so simple that doesn't require JavaScript or CSS for normal behaviors, doesn't use modules like Views, doesn't support user authentication, etc. that means your site should be as simple as a static HTML site.

Anyway, security by obscurity is useless.


There is an official article and discussion regarding the same.

You can't. Do not try

  • Automated attacks (by far the most common attacks) do not even inspect the server before trying their exploits.
    Inspecting the logs of any high-profile site will show thousands of fruitless requests for /AspBB/db/betaboard.mdb _private/cmd.asp /scripts/../../winnt/system32/cmd.exe /wp-login/ /administrator/components/com_wmtgallery/admin.wmtgal, /cgi-bin/ip.cgi ... and any number of attempts at historical exploits on any unrelated system.
    Attacks on exploits happen even if the exploits do not exist on your OS or CMS. Whatever you do to mis-identify your site will be ignored anyway by amateur hackers.
  • Whatever you think you can hide, there are other clues for any system.
    Simply removing the some of all strings that contain 'drupal' does not disguise your site to any reasonable snooper. There are dozens of ways that can be used to guess what is serving your pages, even dedicated services to tell Is that site running Drupal. Just the keywords that you recognize and think are a threat are a minor subset of the real indicators.
    Ask for index.php/?q=user . Then try to disable that response without crippling your site.
  • Security by obscurity is no security. It gives a false impression of being 'safe' when you are only hiding vulnerabilities behind a smokescreen that any attacker that posed any real threat would be able to see through.
  • Although it's not entirely impossible to hack the code to the point where most traces of Drupal are hidden from the HTML source, (It's Open source after all) the steps required to do so would necessarily break core so badly that your hacked branch of the code would be incompatible with the real security updates that you could not patch and would genuinely be open to any real future threats identified by the security team. This is a true route to system vulnerability.
  • Most significant or useful modules have their own code 'signature' that is hard to hide without significant rewrites. If you are using 'views', 'cck', 'ad', 'imagecache', 'jquery', css-aggregation, contributed themes or anything useful on your site - someone can tell. Hiding that entirely would usually require a total conversion of the theme functions - at least. Even then, obsfucation probably won't work.
  • To remove identification of many of the advanced features, like even the easy install of Google Analytics that may use Drupal Libraries to work, you must necessarily either forgo those features altogether, or rewrite them in a way that does not take advantage of the Drupal infrastructure. Sometimes this is possible, but in all cases it is counter-productive.

You may be interested in reading Securing your site too.

Remember Never hack core

  • Although I agree with this, I think that even just as a first line of defence, removing the headers referring to PHP and Drupal is a good thing to do, as well as not allowing access to any non-index php scripts. No, of course people will always find a way of finding out you're running Drupal, and thinking you can hide that is silly. But there's no harm in making life a bit harder for the least discerning hacker. Jan 28, 2016 at 15:52

There is no point in hiding that your site runs Drupal. It is the wrong way to look at developing websites. What you should be focusing on is security. Make sure you implement all securities measures and everything will be fine. There is not one reason in the world to hide that you are using a certain cms or other piece of software. With FF addons like Wappalyzer, you can tell in an instant if a site uses Drupal, so the question is pretty moot.


An extra thing you may do is using also the File Aliases module to change the default file structure.

The File Aliases module allows you to use token customisable aliases for your uploaded files, giving you the ability to keep your file system organised as per usual while providing clean looking paths (i.e., no more /sites/default/files/).

  • 1
    And? That fixes one tiny part of the process and maybe not even the most important part.
    – greggles
    Jan 25, 2012 at 2:21
  • 1
    I didn't want to repeat once more the correct answers of the people above. I just add one more tip.And yes this tip is very important, because it was the most difficult to be done till now, and usually the only way to understand a site is drupal, since usually webmaster do the usual steps except this. And yes, it is very easy to understand that it is a drupal site just because of this file structure/folder organization.
    – john
    Jan 30, 2012 at 20:00

I agree with other people that you can't hide it entirely. If you look at the HTML source, you will notice that many times CSS and JavaScript files haven't been aggregated. CSS and JavaScript aggregation should be enabled.


In that past I've swapped my fonts for the typical Ruby project fonts like Lucida Sans, also increasing input sizes like all the hip kids do.

Another give away is the "throbber" graphic for autocomplete fields. It also doesn't work when you increase the input size. Here's one you can steal: http://beta.seattlebedandbreakfast.com/misc/throbber.gif

Not the answer you're looking for? Browse other questions tagged or ask your own question.