I have a friend who has a website developed in PHP on which we can browse all his files one after one (of course, we can not read the content of the PHP files).

Do you think this is a security hole? If yes, in which sense?

  • 2
    I would just like to add one point. While it may not be a big vulnerability, it is bad UI to show a simple directory listing to the user. If you have a website which has a bunch of widgets profiled (say at "example.com/widgets/a" or "example.com/widgets/b"), it is better UI to show your own resource listing (along with search, and maybe a short intro to widgets) at "example.com/widgets/". A unix directory listing will probably have a bunch of PHP files which make no sense to the end user. Off topic in this forum, but that's why this is a comment and not an answer.
    – Munim
    Apr 26, 2014 at 4:46

6 Answers 6


What you're describing is normal directory listing

enter image description here

In itself, directory listing is not a security issue. If the security of your system is compromised after figuring out the structure of your files and directories, then you're relying on security through obscurity, which is bad. Examples of this bad practice include:

  • Using secret directory names to access sensitive files.
  • Limiting the execution privileged functions to only access their URLs rather than using proper permissions.
  • Leaving special doors/backdoors for developers.

However, as part of a good security policy, after implementing proper security measures, it's beneficial to obscure the working parts of your system. The less you show about your system, the less information an attacker can get on you, which means you're making their job more difficult.

"So, what should I do?" you ask. Simple: Disable directory listing in your web server configurations. In Apache, you go to your httpd.conf and find the line where it says

Options Includes Indexes

Remove Indexes from the line, then restart your apache.

  • 4
    Good answer, although an alternative to disabling indexes (which may have functional implications) is to just add a dummy index.html/index.php file
    – symcbean
    Apr 24, 2014 at 12:23
  • 2
    @symcbean That is if the server is configured to use those files as the index files. However, most of the time that's enabled by default. So, I agree it's a good advice.
    – Adi
    Apr 24, 2014 at 12:35
  • 1
    Not showing the directory contents is important. A website was hijacked because a bored user went through the php directory listing, trying to pass random values to the scripts and found a major security hole in a deleteuser script which always deleted the passed user ID without checking for administrative rights - so the websites user base was gone in an hour.
    – Ray
    Apr 24, 2014 at 13:35
  • 3
    Agree Defense-in-depth = good, security-through-obscurity = bad. Having said that, nobody really thinks it's a good idea to expose the structure and possibly the content of your source code files gratuitously, right? It's great that you can't read the contents of the PHP files. But if you can see the names and paths of those files, which may include configuration or other more sensitive files, how hard is it to presume they're in /var/www/http or /var/www/https and use that information to try to expose them through some other hole or exploit you accidentally left open or don't know about? Apr 24, 2014 at 13:37
  • 4
    Part of the defense in depth strategy is that you make the job hard enough for the bad guys that it isn't worth their time, and they'll move on. The more shiny objects you wave in front of their faces, the more interesting you make your assets, and the more likely it is that they'll spend an inordinate amount of trying to figure out how to crack your system. The more time they spend trying, the worse it is for you... Apr 24, 2014 at 13:40

To add to the answers of @adnan and @william-calvin:

It "may" be a problem ;)

  1. It does reveal names of files that are only accessible by, for example, authenticated users (Think "change_settings.php" for logged-in users). Now this in itself is not a problem. If his website is well written, then he will perform proper authorization checks before loading each file. From another point of view, a good crawler/spider will "map" all files that are accessible anyways.

  2. If he is messy with backups files (think: secret.bak or blah.php.old), then other will be able to read these files. This is also the case for quick phpinfo() and db_dump.sql files.

  3. He may include files, and have these with a non-php extension, such as db.inc, depending on your apache setup, an attacker may be able to read these.

So, as explained by the others - it is bad practice. It gives out more information then it should.

  • 1
    Same goes for logs the website might create.
    – darthmaim
    Apr 25, 2014 at 16:43

Yes.. This is definitely an issue.

If I know your structure, I will be able to get better understanding of your system which makes me easier to attack your system.

It is recommended to turn off your directory listing (See this tutorial if you are on CPanel)

The less hackers know, the harder they need to think..

  • True. However you must be able to have a secure system even in a situation when the directory structure is well known. Think about open-source projects where this is common knowledge (e.g. wordpress). Jul 1, 2016 at 14:51

Yes, regarding to above answers, I don't want to share same information, but real event that happened to my organization.

We had a web server (Front end of which clients can see their internet account information, ability to recharge, etc).

The developer uploaded a BigDump to backup the triple A server data, in that while, an attacker reviewed the directory listening and found dump file which contain all scratch cards and account information, hopefully, he reported to me and we solved this issue.

As also mentioned, relying on security through obscurity, its better to disable directory listening, I made a policy for my organization that this feature should be disabled in all web servers.


To add to Adnan's answer, some PHP frameworks, like PyroCMS, solve the problem in your question by using a combination of .htaccess files and having an index file, named something like index.php, in each and every directory.

An .htaccess file is like an extension to your server configuration in files like php.config, but can be included directly in the site folders, although in certain cases they may not be allowed or may not work because of the server files. Also, you can use them even if you don't have access to the server files, for example if you have a site in the cloud somewhere. They can be used to limit access to files in the directory they are in, or in child folders. PyroCMS and other frameworks often have an htaccess file in every single folder, many of which limit or deny access to the folder and all its subfolders.

index.php is one of the default pages to show when the URL points to the folder, although you can configure these default pages in your server files. For example, if the user navigates to example.com/folder, and there are none of these default files in this directory, the page will show what your friend likely sees, which is probably the view Adnan shows in his answer. However, if there is an index.php file in that folder, the page will instead show whatever is in <site folder>/folder/index.php. PHP frameworks often have an index.php in every or almost every folder and subfolder for you. Many of these files have something like:

    <div>Please don't go here! It's very sensitive!</div>

As these .htaccess and index.php files are already put in all these folders, you don't have to do it yourself, although you can take them out if you want or need to to fit your site. Even if you don't ultimately use these frameworks, downloading a couple and seeing what they do can be helpful in designing your site. Watch out if you do this, though, as many of them are hundreds of megabytes.

By the way, yes, it is bad practice to have these files browsable. The point with this answer is that there are tools you can use to prevent you from having to repeat boilerplate code thousands of times over, sometimes literally, and it just so happens the topics in this question involve boilerplate code these tools can help with.


BTW, there is no httpd.conf in Ubuntu ( right now on 14.04 ; do not search for it, you'll edit apache2.conf file).

To save your PHP driven website from the script kiddies, you can read my long tutorial for hardening WordPress (I provided link for copyright protection plus probably you'll know about more unknown vulnerable points). WordPress is just an example, actually the content is applicable to any PHP-MySQL or even PHP driven website.

Secondly, unrelated to the original question; The Linux Kernel should be hardened too. You can see my gist - https://gist.github.com/AbhishekGhosh/9407137

Normally PHP will not open in the browser like a text file, but showing the path, name and probably gives the indication that the server administrator is not very experienced and makes it more vulnerable.

Do not try to control from .htaccess level, keep .htaccess as light as possible. It is actually in the public directory...

  • 2
    While your points are valid, none of them answer the question that was asked. The sound more like comments to other people's answers. Apr 26, 2014 at 22:32
  • Yes, I agree with you - "none of them answer the question that was asked". May be it was better as comment to trysis. Thanks for the Edit, too. May 10, 2014 at 15:46

You must log in to answer this question.