Download the PHP package codicastudio/csp without Composer

On this page you can find all versions of the php package codicastudio/csp. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package csp

Set content security policy headers in a Laravel app

By default all scripts on a webpage are allowed to send and fetch data to any site they want. This can be a security problem. Imagine one of your JavaScript dependencies sends all keystrokes, including passwords, to a third party website.

Installation

You can install the package via composer:

You can publish the config-file with:

This is the contents of the file which will be published at config/csp.php:

You can add CSP headers to all responses of your app by registering codicastudio\csp\AddcspHeaders::class in the http kernel.

Alternatively you can apply the middleware on the route or route group level.

You can also pass a policy class as a parameter to the middleware:

The given policy will override the one configured in the config file for that specific route or group of routes.

Usage

This package allows you to define CSP policies. A CSP policy determines which CSP directives will be set in the headers of the response.

An example of a CSP directive is script-src. If this has the value 'self' www.google.com then your site can only load scripts from it's own domain or www.google.com. You'll find a list with all CSP directives at Mozilla's excellent developer site.

According to the spec certain directive values need to be surrounded by quotes. Examples of this are 'self', 'none' and 'unsafe-inline'. When using addDirective function you're not required to surround the directive value with quotes manually. We will automatically add quotes. Script/style hashes, as well, will be auto-detected and surrounded with quotes.

You can add multiple policy options in the same directive giving an array as second parameter to addDirective or a single string in which every option is separated by one or more spaces.

There are also a few cases where you don't have to or don't need to specify a value, eg. upgrade-insecure-requests, block-all-mixed-content, ... In this case you can use the following value:

This will output a CSP like this:

Creating policies

In the policy key of the csp config file is set to \codicastudio\csp\Policies\Basic::class by default. This class allows your site to only use images, scripts, form actions of your own site. This is how the class looks like.

You can allow fetching scripts from www.google.com by extending this class:

Don't forget to set the policy key in the csp config file to the class name of your policy (in this case it would be App\Services\csp\Policies\MyCustomPolicy).

Using inline scripts and styles

When using CSP you must specifically allow the use of inline scripts or styles. The recommended way of doing that with this package is to use a nonce. A nonce is a number that is unique per request. The nonce must be specified in the CSP headers and in an attribute on the html tag. This way an attacker has no way of injecting malicious scripts or styles.

First you must add the nonce to the right directives in your policy:

Next you must add the nonce to the html:

There are few other options to use inline styles and scripts. Take a look at the CSP docs on the Mozilla developer site to know more.

Reporting CSP errors

In the browser

Instead of outright blocking all violations you can put a policy in report only mode. In this case all requests will be made, but all violations will display in your favourite browser's console.

To put a policy in report only mode just call reportOnly() in the configure() function of a report:

To an external url

Any violations against to the policy can be reported to a given url. You can set that url in the report_uri key of the csp config file. A great service that is specifically built for handling these violation reports is http://report-uri.io/.

Using multiple policies

To test changes to your CSP policy you can specify a second policy in the report_only_policy in the csp config key. The policy specified in policy will be enforced, the one in report_only_policy will not. This is great for testing a new policy or changes to existing CSP policy without breaking anything.

Using whoops

Laravel comes with whoops, an error handling framework that helps you debug your application with a pretty visualization of exceptions. Whoops uses inline scripts and styles because it can't make any assumptions about the environment it is being used in, so it won't work unless you allow unsafe-inline for scripts and styles.

One approach to this problem is to check config('app.debug') when setting your policy. Unfortunately this bears the risk of forgetting to test your code with all CSP rules enabled and having your app break at deployment. Alternatively, you could allow unsafe-inline only on error pages by adding this to the render method of your exception handler (usually in app/Exceptions/Handler.php):

where AppPolicy is the name of your CSP policy. This also works in every other situation to change the policy at runtime, in which case the singleton registration should be done in a service provider instead of the exception handler.

Note that unsafe-inline only works if you're not also sending a nonce or a strict-dynamic directive, so to be able to use this workaround, you have to specify all your inline scripts' and styles' hashes in the CSP header.

Testing

You can run all the tests with:

Changelog

Please see CHANGELOG for more information what has changed recently.

License

The MIT License (MIT). Please see License File for more information.


All versions of csp with dependencies

PHP Build Version
Package Version
Requires php Version ^7.4
illuminate/http Version ^8.0
illuminate/support Version ^8.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package codicastudio/csp contains the following files

Loading the files please wait ....