On his blog today Freek Van der Herten has a post introducing a new Laravel package designed to help make CORS implementation simpler in your application. CORS headers are, essentially, what allows clients (like browsers) to talk across domains in a configurable and enforceable fashion.

Recently we released laravel-cors. This package can add the necessary CORS headers of your Laravel app. In this post I'd like to give a quick explanation of what CORS is and how you can use the package.

The post starts by explaining a bit about CORS (Cross-Origin Resource Sharing) headers, what they're used for and simple examples of when they might be most useful. It then covers the package, showing how to pull it into your packages and adding it to the middleware configuration for loading on each request. There's also a more detailed configuration you can use to defined allowed and denied domains as well as the idea of "profiles" for different user levels.

In a recent post to his site Aidan Woods shares information (and code) related to the use of secure headers in PHP applications. He's even created a package to help make it easier to drop them into a new or existing project without too much trouble.

Recently I've been working on a drop in class to manage certain "Secure Headers" in PHP. By "Secure Headers", I'm of course talking about those mentioned in the OWASP Secure Headers Project. The project, SecureHeaders is available on GitHub.

He starts by covering why he created the library and what it can help you with including making things like a CSP policy easier to maintain. The article goes on to talk about the Content-Security-Policy header is and what kind of prevention it applies. He also shares how the package displays errors, modifies cookies to secure them (HTTPOnly and Secure flags) as well as provide a "safe mode" that "place an upper limit on things like HSTS and HPKP, and remove flags like includeSubDomains or preload until the header is manually added as a safe mode exception, or safe mode is disabled."

The Laravel News site has a recent post showing you how to integrate HTTP2 support into your Laravel-based application using some simple middleware.

As we all know technology changes fast and if you don’t stop and look around once in awhile, you could miss it. HTTP/2 is one area of our tech stack that I haven’t been keeping up with an honestly knew nothing about it until Laracon where Ben Ramsey gave a talk on the subject.

You can watch his talk here and his slide deck is available from his site to browse through. What amazed me is how easy it seemed to implement by utilizing server push or preload.

They describe this "Link" header process could work if done manually but points out that doing that manually for every asset is very time consuming. To help out they point out two packages that can help make it a bit more automatic. The post briefly shows their use (code example) basing the asset list on the contents of your Elixir configuration.

Recently a major security vulnerability was announced centering around the the HTTP "Proxy" header and how incorrect handling could result in major issues with external requests. In the PHP ecosystem, a major HTTP library - Guzzle - was vulnerable (along with any application using it). However, according to Michael Dowling, a lead developer on the project, a new release has already been made to correct the problem.

httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict [between the "Proxy" and "HTTP_Proxy" headers]. This leads to a remotely exploitable vulnerability. If you’re running PHP or CGI, you should block the Proxy header now. Here’s how.

The main HTTPoxy site as more information about how you can test to see if your application is vulnerable and what software/server configurations are typically vulnerable. There's also more language-specific information on the page as well as some immediate mitigations for various web server types.

In this post to his site Paul Jones makes some suggestions about how to handle session cookies (PHP's default session handling mechanism) and requests/responses using the PSR-7 structure.

One of the great things about PHP is its session handling capabilities. One call to session_start() and a huge amount of heavy lifting is done for you. It’s a great aid when writing page scripts.

However, as you start to need finer control over the HTTP response in your project, some of the automatic session behaviors begin to get in the way. In particular, when you are using PSR-7 to build your HTTP response, you realize that session_start() and session_regenerate_id() both automatically do the equivalent of calling setcookie() to write headers directly to the output. This means you cannot buffer those calls into the Response object for later sending.

How then can we use PHP’s session handling, when we want finer control over when and how cookies get sent?

He suggests that you do two things. First, disable PHP itself from automatically sending the cookie via some ini_set calls. The second is to do the session ID comparison manually and perform the related action (either allowing or sending a new ID on failure). He includes example code showing it in action and also mentions some of the shortcomings of the approach around cache and limiter headers.

On the Zend Developer Zone they've posted the fourth part in their series of tips around using the Z-Ray profiling tool in your PHP applications. In this fourth tip they show you how to "get rid of it" in certain parts of your application.

Well, while Z-Ray is a great friend to have when developing your apps, there are just some parties you don’t want it to show up at. You might be using PHP scripts for accessing static pages. Or, you might not want Z-Ray to be displayed for one specific request. In production, you most definitely don’t want Z-Ray popping up for users using your app!

There are numerous ways to disable Z-Ray both in development and in production to make sure your development workflow is not interrupted and your live apps are not affected. Here are a few of them.

They include a few different ways to disable the tool including the use of a function call in the code (zray_disable), using a header in the HTTP request and, naturally, from the Z-Ray toolbar itself. They also talk about setting it up to be removed for production in one of two modes, either selective (only showing for certain requests) and completely disabled.

Rob Allen has a quick post to his site talking about some of the improved error handling that's been updated in the latest version of the Slim microframework to help make reporting issues easier in multiple contexts.

From RC1 of Slim 3, we have improved our error handling. We've always had error handling for HTML so that when an exception occurs, you get a nice error page [...] However, if you're writing an API that sends and expects JSON, then it still sends back HTML. [...] At least we set the right Content-Type and status code! However, this isn't really good enough. We should send back JSON if the client has asked for JSON. Until RC1, the only way to do this was to register your own error handler.

With Slim 3 the framework handles things more correctly based on the value of the "Accept" header sent along with the request. This value is checked and, if it references JSON or XML, the error message is translated either giving the default output or reporting back for the "notFound" and "notAllowed" error types.

Matthew Weier O'Phinney has a new post to his site talking about PSR-7 and HTTP headers and how they (headers) are handled in the structure of this PHP-FIG specification.

Yesterday, a question tagged #psr7 on Twitter caught my eye: "When I call $request->getHeader('Accept') for example, I was expected that I'll get [an array] but, in reality I got [a string]. Is this correct?" In this post, I'll explain why the behavior observed is correct, as well as shed a light on a few details of header handling in PSR-7.

He talks about the planning that went into PSR-7 and how they had to work around some of the "flexibility" (quirks) in the HTTP specification. This was especially true when it came to repeated headers. He also walks through their thoughts on multiple header handling and that custom header values are allowed. Because of these two things, they decided to treat all headers as collections and, despite there being separators already in the values. Instead they collected headers of the same types into these collections, some containing only one value while others could contain multiple. Back to the question - this explains why the "Accept" header they desired was still in its comma-separated form and not split into the array they expected.

The [...] example provides another good lesson: Complex values should have dedicated parsers. PSR-7 literally only deals with the low-level details of an HTTP message, and provides no interpretation of it. Some header values, such as the Accept header, require dedicated parsers to make sense of the value.

Barry vd. Heuvel has a recent post to his site explaining how the Laravel framework has implemented CSRF protection natively. CSRF is short for Cross-site request forgery and is a type of security vulnerability.

In this blog we take a closer look into CSRF protection in Laravel. We compare the difference between the CSRF filter in Laravel 4 and the current VerifyCsrfToken middleware in Laravel 5.

He start with a quick look at why CSRF protection is even needed and what kind of problems it can cause. He shows how the CSRF protection was enabled in the Laravel 4 routing and how, in Laravel 5, the token evaluation was updated to use the hash_equals to prevent timing attacks. He then gets into the details of the middleware and how it handles the protection for you (including detection and use of the X-CSRF-TOKEN header).

On the Qandidate.com blog today there's a new tutorial talking about the use of the Accept header in REST HTTP requests and, more specifically, working with it in a Symfony-based application.

I investigated different ways to version a REST API. Most of the sources I found, pretty much all said the same thing. To version any resource on the internet, you should not change the URL. The web isn't versioned, and changing the URL would tell a client there is more than 1 resource. [...] Another thing, and probably even more important, you should always try to make sure your changes are backwards compatible. That would mean there is a lot of thinking involved before the actual API is built, but it can also save you from a big, very big headache. [...] Of course there are always occasions where BC breaks are essential in order to move forward. In this case versioning becomes important. The method that I found, which appears to be the most logical, is by requesting a specific API version using the Accept header.

He shows how to create a "match request" method in his custom Router that makes use of the AcceptHeader handling to grab the header data and parse it down into the type and API version requested. He also includes an example of doing something similar in the Symfony configuration file but hard-coding the condition for the API version by endpoint.