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)?

  • 76
    You don't want to hide Drupal. Drupal is awesome. – Damien Tournoud Mar 16 '11 at 17:39
  • 4
    How about deleting the CHANGELOG.txt file from the root directory for a start! No but seriously - sounds like a complete waste of time to me. Keep upto date with the security updates and there is no need to hide the fact that it's Drupal. Does The Whitehouse hide the fact that they are using Drupal? No, they shout it from the rooftops :) – Tom Kirkpatrick May 14 '11 at 23:08
  • 10
    In this instance security through obscurity does not offer more security. – Bryan Casler Jul 21 '11 at 9:21
  • 3
    You might want to read Cacking Drupal: a drop in the bucket, which is an excellent treatise on securing your Drupal site. – Mawg says reinstate Monica Sep 23 '11 at 3:05
  • 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 it's 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. – user56reinstatemonica8 Aug 12 '12 at 1:06

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.).

| improve this answer | |
  • You forgot Drupal JavaScript object that needs to be renamed. – Mołot Oct 23 '13 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 '13 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 '13 at 19:56
  • Correct. It's not worth your time. Focus on more important things :) – greggles Oct 26 '13 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.

| improve this answer | |
  • 7
    Agreed. Another dead give-away are the structure of the CSS/JS/image paths. – Fuzzy76 Mar 3 '11 at 13:05
  • 2
    You can also visit /node/1 and see what comes up or check the HTTP headers. – Paul Jones Mar 3 '11 at 13:25
  • 40
    If you try to hide your site with security through obscurity, you're just going to be wasting your time. – Dave Reid Mar 3 '11 at 14:40
  • 6
    Agreed with all the above. Plus, it would then be harder for people who do CMS comparisons to see how many awesome sites are running Drupal ;-) – geerlingguy Mar 3 '11 at 18:03
  • Relevant to what geerlingguy is saying was the discussion we had here: groups.drupal.org/node/113024#comments – coderintherye Mar 3 '11 at 23:19

It's too easy to do, kiam!

  • 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 url 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

And last but not least, make sure that your site is so simple that does not require JS or CSS for normal behaviors (don't use Views or Ctools...), does not support user authentication, etc. that means your site should be as simple as a static html site.

Ok, all that to make people believe that your site does not run Drupal. Anyway, security by obscurity is useless.

| improve this answer | |
  • @jcisio "Anyway, security by obscurity is useless.", you should have added this on top of your comment :P . – arpitr Sep 11 '13 at 9:12
  • @arpitr Everybody else does it, so I think I don't need to ;) – jcisio Sep 12 '13 at 8:30

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

| improve this answer | |
  • 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. – Matt Fletcher Jan 28 '16 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.

| improve this answer | |

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/).

| improve this answer | |
  • 1
    And? That fixes one tiny part of the process and maybe not even the most important part. – greggles Jan 25 '12 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 '12 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.

| improve this answer | |

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

| improve this answer | |

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