Home > Deployment > Same Site Cookies

Starting in late 2019 several major browser vendors implemeted a new security mechanism called Same-Site Cookies.

The purpose of this change is to restrict information that can be set and accessed by any domain that's not the primary domain you're currently visiting. This affects form creators as a common deployment pattern is placing an iframe to www.b.com on a site www.a.com. In this case the iframe form domain, www.b.com, is prevented from setting any cookies.

Blocking cookies in this manner presents a critical issue, as in order for a form to process fields and submit results it must save page requests to just such a cookie. If cookies are blocked this cannot happen, and users will not be able to submit results or even navigate to other pages in the form.

Implications

While an important security feature the unfortunate side-effect of this change is the way we deploy and use forms will need to change. As of now their are two main types of mitigation. The first is changing how we create and deploy forms, the second is to update your server's software to better handle the new restrictions.

Note: The following discussion only applies to self-hosted versions of RackForms. Our cloud hosting solution has been patched and fully supports the new secure cookie standards.

Changing Form Creation And Deployment

The first class of fix is to simply avoid the new restriction by changing how we create and deploy forms. This starts with building forms that are simply not embedded within another page. RackForms has a wealth of tools for styling full-page forms, meaning we can simply direct users to a full form page and redirect back to our original page upon completion.

A second version of the first fix is to host forms and parent content on the same domain. That is, if our parent page is www.a.com, the form is also hosted on the same server (www.a.com).

The next class of fix is technical and involves updating our server platform to confirm with the new specification.

Updating The Server

To ensure your forms run appropriately in this new security context a few steps must be taken:

• First, edit your php.ini to enable secure, http only cookies:
  
  session.cookie_secure = 1
session.cookie_httponly = 1
  
  
• Next, we'll tell the PHP session system to tag each cookie request with: SameSite = None

  This setting's implementation differs based on your PHP version. If running 7.3.1 or higher we'll simply update our php.ini as follows:

  session.cookie_samesite=Never
  
  

  If running a PHP version older than 7.3.x we'll need to configure our web server to modify each cookie request. In this case we'll cover Apache, please check with your server vendor for others.

  Start by making sure mod_headers.so has been enabled. This task will differ based on your OS and server management software, but will eiether be modifying your httpd.conf directly and making sure this line doesn't have a # in front:

  LoadModule headers_module libexec/apache2/mod_headers.so
  
  

  Alternatively, use your server's management tool, such as Webmin, to enable the headers module.

  Now that we have Apache headers enabled, we'll need to create or modify an .htaccess file so that each header cookie request appends the SameSite=None tag.

  As noted, if you do not already have an .htaccess file we'll need to create one first. Please note the (.) at the start of the name is intentional, as these denote hidden files on Unix systems. Where to place this file? .htaccess files are Apache's way of defining directory level configuration values. Thus, if RackForms was installed at: /www/htdocs/rackforms We would create the file at: /www/htdocs/rackforms/.htaccess

  To the web server then, any request for pages under this directory will inherit the configuraton settings defined at the parent. This is exactlly what we want for forms we create, as those files live in a child of the main directory our configuration values reside in.

  With the location decision made, open the .htaccess file and add the following line:

  Header always edit Set-Cookie (.*) "$1; SameSite=None;Secure"

  With these steps complete the server should now be sending the proper cookie flags.

  We can test our configuration by opening your browsers web developer tools and viewing the cookies in the Storage (firefox) or Application (Chrome) tab. Look for the cookies section and expand. If your cookies are being sent properly they'll have checkmarks or the word "Secure" for the Secure column, and "None" for SameSite.

Summary

In summary, new cookie rules mean deploying forms is a bit more difficult than it used to be. In many cases the easiest solution will be to simply host forms on the same domain as the parent page. Failing that, the next best solution is to simply build full-page forms and link users to them from your parent site. Finally, we can also modify our server software so that we append the SameSite attribute to secured cookies.