The archives composer.lock
is a generated version of your file composer.json
which contains the exact versions of the dependencies your application is running. It is updated with a composer update
and if the file exists while running composer install
, instead of downloading the versions most recent, he will download the versions of that file (ideal in development teams, to know the exact dependencies).
The risk of exposing this file would be that a possible attacker knows exactly what dependencies your project uses and exploits vulnerabilities/bugs specific to these versions of dependencies, so he knows where exploit a security breach.
To avoid such problems it is a good practice to separate the business logic (its classes, connection to bank) from the files sent to the browser (index.php
, css
, js
and images) at the root of the webserver.
Frameworks usually have a folder public or web at the root of the project. This folder is the one that is usually mapped on as the root of the web server, keeping out the framework classes and files like composer.lock
. Below is an example of the folder structure of the Laravel:
In this example we have the system itself outside the root of the web server, in the folder app
. The browser in the case would only see what is inside the public
, which in this case are the files .js
and .css
with the index.php
that invokes the framework:
Completion
Not only the composer.lock
, but any file that is not really necessary to be accessed by the browser should stay out of the web root of your application. Depending on the configuration of your webserver, it is possible for even an attacker to download your entire system, and since PHP is not complicated, it would have all its work without difficulties.