将多个Laravel项目置于public_html下是否仍存在安全风险？

Great question! You’ve already locked down some critical areas—pointing domains to the public directory, disabling directory listing, and blocking .env access are all smart moves. That said, there are still a few potential vulnerabilities to address in your setup:

1. Unrestricted Access to Non-Public Project Files #

You’ve blocked .env, but other sensitive files/directories in your project roots (like composer.json, composer.lock, .env.example, or the vendor folder) might still be accessible if someone knows their exact path. For example, an attacker could request yourdomain.com/../project1/composer.json to get your Laravel version and dependency details, then target known vulnerabilities in those packages.

Fix: Add an .htaccess file in each project root (e.g., public_html/project1) to deny all access:

# public_html/project1/.htaccess
Require all denied

This ensures no one can directly access any files outside the public folder, even if they guess the path.

2. Incomplete Path Traversal Protection #

While Options -Indexes stops directory listing, it doesn’t prevent path traversal attempts (using ../ to jump up directories). If your server’s configuration or root .htaccess doesn’t block these attempts, attackers could still reach files outside the intended public directory.

Fix: Add path traversal protection to your root public_html/.htaccess:

RewriteEngine On
# Block any request containing ../
RewriteCond %{REQUEST_URI} ^/../ [NC]
RewriteRule ^ - [F,L]

This returns a 403 Forbidden for any request trying to traverse up from the public directory.

3. Laravel Configuration Oversights #

Even with solid server setup, misconfigured Laravel settings can expose risks:

• Debug Mode: If APP_DEBUG=true in production, error pages will leak sensitive details like file paths, database structure, and code snippets. Always set this to false for live sites.
• Environment Setting: Ensure APP_ENV=production—this disables development-only features and enables production-level security checks.
• Storage Permissions: The storage directory (used for logs, cached data, etc.) needs proper permissions. Aim for 755 on directories and 644 on files, and make sure it’s owned by the web server’s user group to avoid excessive write access.

4. Virtual Host Configuration Risks #

Double-check your virtual host settings to confirm:

• Each domain/subdomain strictly points only to its project’s public folder—no overlap or accidental access to other projects.
• PHP execution is disabled in non-public directories. If your host allows PHP to run anywhere in public_html, an attacker who manages to upload a malicious PHP file to a project root could execute it. Most reputable hosts block this by default, but it’s worth verifying.

5. Dependency Vulnerabilities (Bonus) #

Not directly a deployment issue, but critical for overall security: Outdated Composer dependencies often have known vulnerabilities. Regularly run composer audit to scan for risks, and update packages with composer update (or composer update --patch for safer patch-only updates).

By addressing these points, you’ll harden your deployment significantly. Your current setup is a good foundation—these steps just fill in the remaining gaps.

内容的提问来源于stack exchange，提问作者Jk33