TL;DR: Serve a website from the project root instead of the public directory and you will expose your .env file, potentially leading to huge security issues with sensitive data leakage.
What’s the fuss about and what’re the risks? 🙄
The public directory in your Laravel project plays a crucial role in your application's structure. It serves as the entry point for the application and is the most secure folder to serve your production website from.
Laravel’s rapid ascend to be one of the most popular PHP frameworks, has in some cases removed too many barriers for entry-level developers using it who fail to consider proper deployment procedures and to ensure optimum performance and security.
Whilst setting the document root of your web server to the public directory might seem like a minute detail, but it's of paramount importance as highlighted in this 2019 exploit.
We were over it at the time and couldn’t believe the thousands of results we saw. Having just revisited the article for a client meeting though to talk about security practices, we were still amazed to see hundreds of results in Google.
Exposing sensitive information
Laravel’s structure has directories like config, database and .env outside the public directory for good reason.
These directories house confidential configurations, database migrations, seeds and environment variables that if accessible by a bad actor give them far more information than they could ever ask for.
If your document root isn't correctly set, these directories risk being exposed to the outside world. Directly accessing files outside the public directory could lead to arbitrary code execution or data leaks.
Respecting Laravel’s design
Respecting the Laravel design — that the public directory is the entry point to your application — ensures you're using the framework as intended; benefiting from its robustness and avoiding unintended behaviours.
Simplifying configuration
Serving files directly from thepublic directory simplifies various configurations for you too. For example, you don't have to rewrite paths or set up additional rules to handle asset requests.
Controlled error display
Exposing the entire Laravel application could lead to unhandled errors being displayed to users that you’re not considering, potentially revealing sensitive information you’d rather not.
By limiting exposure to and serving content from the public directory, you ensure that users only see errors that have been purposely handled for the production environment.
Clear separation of concerns
Using this set-up, serving your application from the public directory as intended, there’s a clear demarcation between what’s accessible to the end user and what’s part of your more sensitive application logic.
This clarity is beneficial for developers and systems administrators alike.
What to do if our .env file has been exposed? 🤦♂️
If your .env file contents have been exposed — or even if you think it might have been exposed — it's crucial to act promptly and decisively to mitigate potential risks.
Here are some Ascend tips on how to handle such a problem:
Rotate Secrets and Credentials 🔄
- Database: Change your database username and password.
- API Keys: Rotate any API keys or secrets listed in the
.envfile. - Mail Servers: If you’re not using an API driven system — why?! — update mail server credentials if they’re present.
- Third-Party Services: Rotate the credentials for any other third-party services you’ve configured in your
.envfile. - Refresh your APP_KEY: If the
APP_KEYwas exposed, generate a new one usingphp artisan key:generate. Note that this will invalidate all existing sessions and encrypted data at rest — SO DON’T JUST RUSH BLINDLY INTO THIS.
Review Server and Application Logs 🔎
Check for any suspicious activity. Unauthorised database access, abnormal API call patterns and unfamiliar IP addresses can be indicative of breaches.
You may also find in log files direct access to non-Laravel .php files that would be indicative of a shell being present on your server.
Ensure .env isn't publicly accessible 🚫
Make sure that your server’s document root is correctly set to the public directory of your Laravel application. There’s no point doing all of the above if you’re just going to hand the new details over to the bad guys.
If you’re struggling serving from
publicyou could use server configuration to deny access to the.envfile directly, even if could in theory get access to it via a browser.
A good check to make is that your .env file is in your .gitignore file to prevent it from being accidentally committed. If your repository is public and your .env file is committed, then you’re doing yourself dirty when your server set-up might be perfectly fine.
Notify Affected Parties 📞
If any of the exposed information had data related to users or other stakeholders, you must inform them about the breach. Depending on where you are in the world, there might be legal requirements about notifying affected individuals or entities.
Remember good old, GDPR?
Review, monitor — but most importantly — learn 💪
Analyse how the .env file got exposed in the first place to prevent similar incidents in the future.
If the security breach was due to human error, ensure developers and non-technical team members are aware and trained on best practices.
If it was due to software or a service, consider alternative solutions or configurations.
After you have taken the above actions, for an extended period on the other side of the security breach, continue monitoring your applications and servers. You’re looking to catch any previously undetected and lingering threats.
Ascend to the rescue 🚀
Navigating the aftermath of a security breach can be overwhelming and intimidating. Immediate but sensible actions are crucial. So too is finding a long-term solution to ensure it doesn’t happen again.
Ascend is positioned in the marketplace to help you rise above these challenges.
With a robust security checklist tailored for Laravel applications, Ascend can help ensure that you’re not just reacting to a threat but proactively preventing a future one too.
Don’t wait for another vulnerability to take action.
