Organize website code to prevent accidentally exposing code or other information that should remain private.
- In the theater, the audience should see the action on the stage, but not the activity backstage. You wouldn't want the audience watching the set changes or wandering through the dressing rooms. There's a clear division between what gets shown and what remains hidden. The same is true for our code. Websites present visual information to users, but users should not see the work behind the scenes that makes it happen. Controlling output includes controlling visibility. A behind-the-scenes look at our code would provide a lot of valuable information for a hacker. They could see what security defenses were being used and pinpoint its weakest links. So we should keep all code private. The first step you can take to control visibility is to organize code into two separate directories, public and private. You can think of them as on stage and backstage. The public directory will be accessible by the web server. It provides a point of entry to our website. It will contain the pages we want the public to see. The private directory won't be accessible by the web server. However, the files in this directory will be accessible by your code, because it has access to the file system. Most web frameworks organize code into public and private directories for you. Once code is split into public and private directories, the web server needs to be configured to serve files from the public directory. And you do that by setting the public directory as the document root in the web server configuration file. This tells the web server where to find files that should be accessible to the public, and prohibits it from serving files which are not inside that directory. Pages in the public directory can contain private code. For example, a public page can contain PHP code, which users should not see. The user won't see it because the web server will process the PHP and output HTML. While these pages can contain code, it's still smart to keep that code to a minimum. Make it boring, create functions for the interesting parts, store those in private files, and then load and call them from the public files. If for any reason the web server failed to process the page correctly, the exposed code will be minimal and harmless. The good stuff will be backstage in the private directory. It may take some reorganization of your code to have a clear division between code that should be public and that that should be private. But the increased security is worth the effort.
- Threat models
- Least privilege
- Defense in depth
- Validating and sanitizing input
- Credential attacks
- SQL injection
- Cross-site scripting