I'am wondering if it's really safe to use this structure of my web application.


If I point a website root folder to the /public, so if someone comes to my web page i.e.: www.mywebsite.com ... he will be accessing the /public folder where the index.php is located. My question is, will it be really that safe to not moving my application's core files into the /public folder but into upper level instead ?

Or is it possible to access the webapp/application/ and webapp/framework/ from webapp/public/ folders by some hackers ?


Normally all *.php files (if setup correctly) will be executed, and nobody will be able to download it's source code. When you have files such as db-functions.inc, people may be able to render this in their browsers; which is what you don't want.

The handy thing of having non-public accessible directories is that you can store backups files (dbdump.sql, backup.zip, ....) and you won't be able to download it directly from the browser..


Or is it possible to access the webapp/application/ and webapp/framework/ from webapp/public/ folders by some hackers ?

Unfortunately, yes. Although it's not possible to go to the directory directly (on proper web server software, one cannot simply do www.site.com/../hidden/hiddenfiles.zip), if your website has directory traversal vulnerabilities , it may be possible to access files outside of your webroot.

Input sanitation is key, the linked wikipedia article is actually a good read-up.

| improve this answer | |
  • if attacker knows the exact structure of my non-public folder structure, could he get an access to for example webapp/application/inc/database.php where the password are stored for database, by using some sort of function inside webapp/public/index.php with require('../application/inc/database.php'); ? – aspirinemaga Apr 27 '14 at 14:34
  • He could if your site is vulnerable. If you, for example, perform a: require('../application/inc/'.$theme.'.php);, and if he has access to the $theme variable. If you hard code your paths, then it is unlikely to happen. – ndrix Apr 28 '14 at 5:31

If your code is not vulnerable to local file inclusion / directory traversal and you configured your server correctly, it will not be possible to access /webapp/application or /webapp/framework/

And to your question: yes, it would be a bad idea to move the core files inside /public. That's why the creators of the framework created the public directory :) If the directories contain configuration files, it is quite possible that they can be read by an attacker. But even if it only contains php files, it is still a security risk. Calling those files directly might have unintended consequences, at a minimum I would expect low-level information like paths etc to leak.

| improve this answer | |
  • i think I got the idea. By using any PHP framework, theoretically it should be already done in some global instance which is not accessible to public, right ? something like bootstrap.php ? – aspirinemaga Apr 27 '14 at 14:37

You need to configure your web server so that only the contents of the Public directory is public. If the web server is correctly configured, no other content will be accessible to HTTP requests.

| improve this answer | |
  • I think my web server is configured correctly, it uses the structure I showed you above. Would you apply some other security steps to protect your app a bit more ? If there is any of course. Thank you – aspirinemaga Apr 27 '14 at 14:39
  • 1
    Like I said, in the configuration of the web server: Some directories can be set as "public", others not. So if you set the correct directories to be "private" (set in the web server's configuration), you'll have nothing to worry about. Of course, assuming that the web server software you're using is implemented correctly (from an InfoSec point of view): Isn't vulnerable to hacking. – Steven Volckaert Apr 27 '14 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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