Check For Security Vulnerabilities in Your Laravel Packages

Being popular isn’t always great. PHP is often the target of many security breaches especially since almost 80% of the web runs on it.

Here’s a quick way to check if your Laravel includes have known security issues:

wget -O - | bash
sudo mv /home/aryeh/.symfony/bin/symfony /usr/local/bin/symfony
symfony security:check --dir=/path/to/composer.lock

The path should just be the folder path (don’t include composer.lock in the path). You should see something like this:

Then, just edit your composer.json to the latest version for that package and do:

composer update

Usually this makes the issue go away.



Implementing a Content Security Policy (CSP) in Laravel

Once a webpage leaves your servers, anything can happen to it. Sometimes, the client’s browser tries to execute scripts against your page that range from the benign changing of font colors to nastier XSS attacks that manipulate and steal user data.

This is where a Content Security Policy comes into play. It basically instructs the browser what kinds of content is allowed to load for your site. This includes restricting loading of external scripts, images and any other files that might want to load on top of your page.

Implementing this is quite easy in Laravel:

  1. composer require spatie/laravel-csp
  2. php artisan vendor:publish --provider="Spatie\Csp\CspServiceProvider" --tag="config"
  3. Then, add it to your middleware in app/Http/Kernel.php:
protected $middlewareGroups = [
        'web' => [
             // other middlewares

Your CSP is set up! You can view the directives in vendor/spatie/laravel-csp/src/Policies/Basic.php . This is a bit restrictive though, so you might want to publish your own policy instead. Here’s one I used recently:


namespace App\Services\Csp\Policies;

use Spatie\Csp\Policies\Policy;
use Spatie\Csp\Directive;
use Spatie\Csp\Keyword;

class MyPolicies extends Policy
    public function configure()
            ->addDirective(Directive::BASE, Keyword::SELF)
            ->addDirective(Directive::CONNECT, Keyword::SELF)
            ->addDirective(Directive::FORM_ACTION, Keyword::SELF)
            ->addDirective(Directive::IMG, [
            ->addDirective(Directive::MEDIA, Keyword::SELF)
            ->addDirective(Directive::SCRIPT, [
            ->addDirective(Directive::OBJECT, Keyword::NONE);

You can learn about what the different policy directives mean in the Content Security Policy Quick Reference Guide. In my own policy above, I allowed image blobs and base 64 image data, as well as letting Google in because of Recaptcha and Analytics.

  1. Create your new policy. I saved mine in app/Services/Csp/Policies/MyPolicies.php. Feel free to use my own policy above as a starting point for your own.
  2. Go to config/csp.php
  3. Replace the content so that it will use your new policy instead

use App\Services\Csp\Policies\MyPolicies;

return [

     * A policy will determine which CSP headers will be set. A valid CSP policy is
     * any class that extends `Spatie\Csp\Policies\Policy`
    // replace the default policy
    //'policy' => Spatie\Csp\Policies\Basic::class,
    'policy' => MyPolicies::class,

     * This policy which will be put in report only mode. This is great for testing out
     * a new policy or changes to existing csp policy without breaking anything.
    'report_only_policy' => '',

     * All violations against the policy will be reported to this url.
     * A great service you could use for this is
     * You can override this setting by calling `reportTo` on your policy.
    'report_uri' => env('CSP_REPORT_URI', ''),

     * Headers will only be added if this setting is set to true.
    'enabled' => env('CSP_ENABLED', true),

     * The class responsible for generating the nonces used in inline tags and headers.
    'nonce_generator' => Spatie\Csp\Nonce\RandomString::class,

Now that you have your CSP set up, you can check it by entering your site in Google’s CSP Evaluator. Mine showed this:

Of course, this is just a guide, no need to be alarmed if it says high severity. For me, the script-src finding was okay because I needed to allow Google scripts to run on the site. So evaluate your results based on how your webapp works and don’t force your site to get all green checks in this test.

Hope to see more people securing their site via CSP!

Source: Christoph Rumpel

Disable XML-RPC in WordPress

Ah, the pitfalls of a popular framework. Everyone uses it therefore it’s easy to get coding help but everyone also abuses it so any and all exploits will be sussed out.

One of these is such a basic feature that I think everyone should turn off: XML-RPC. I won’t go into all the details but suffice it to say that it’s bad. And if you do want to access your WordPress site remotely, say like a headless CMS, then use REST instead of XML. It’s much better for your health, trust me.

Here’s how to disable it:

  1. Go to your site root’s .htaccess file
  2. Insert this snippet at the top:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order allow,deny
deny from all

You should be good. Double check if it worked by testing it here: You should see that comforting red X in the next screen.

Source: WordPress StackExchange

Where To Find Remote Dev Jobs in 2020

Here’s my big list of remote dev jobs. Made this as part of my research for a future app idea. Also includes sites where you can get full-time local dev jobs.

TIP: First, check if the job fits you by checking the job responsibilities. Then, check the job qualifications to see if you fit the job.

{{remote_dev_ job_boards}}