Tip: securing your web applications by using secure (HTTPS) session cookies

Tip: securing your web applications by using secure (HTTPS) session cookies

When you access a web application in HTTPS all communications between your web-browser and the web server are secure and only visible by you and the destination. However, if you begin navigating in a web application in HTTP and then switch to HTTPS you are susceptible of re-using some information in your secure session that others may have had access to earlier.
One such piece of information is your session cookie. When you first access a web site using HTTP all the communications are in plain text – and an attacker might easily gain access to a specific piece of information – your session cookie. If that happens that attacker might be able to present himself to the system as if it were you by simply reusing your session cookie.
If you do not know what a cookie is you can read all about it here: http://en.wikipedia.org/wiki/HTTP_cookie

Secure cookies
To avoid these problems there is the notion of secure cookies. Secure cookies are normal cookies that the web-browser receives but which it only sends back to the server if the connection used is HTTPS. This security enhancement also dictates on how the web applications should work: a secure cookies should only be sent by the web server on a HTTPS connection.
Secure cookies can be easily enabled in the Agile Platform to achieve this extra security milestone. When you do so, the following occurs:
  • When the user accesses your web application on HTTP it will not have any session context. Specifically it will produce a completely distinct session on each new web-request. This means you will lose the ability to access web pages which require OutSystems authentication;
  • When a user logs in (on HTTPS) it will be able to access any page using HTTPS and will keep session context. However, if the user moves to a HTTP part of the website its session will be lost – and upon moving back to the HTTPS section the user will need to log back in.

All of this means that, to pursue a secure cookies strategy for your session cookie you must ensure your application only has links using HTTPS. If you are only using links to public screens in your applications you have the problem solved by the Agile Platform. If not, you need to ensure you only use relative links – or that you hardcode the HTTPS on all links you produce manually.

How to set up secure cookies
Since Agile Platform applications are actually standard .NET web apps deployed in IIS, the simplest way to activate secure session cookies is to do it at the .NET Framework level. This can be done in two ways:
  • For all applications in one or all front-ends;
  • Configured for one or more individual eSpaces (in all the front-ends).

Note however that segmenting this for individual eSpaces requires that users access them in separate domains – which we can discuss later if some asks for it.
Setting up secure cookies is done using the requireSSL property of the httpCookies element in .NET (documentation from microsoft).

Set secure cookies for all applications in one or all front-ends
To set the secure cookies at front-end level you can just apply the setting in the global web.config file of the front-end you wish to configure. The file is located at %WINDIR%\Microsoft.NET\Framework64\v2.0.50727\Config\web.config, inside the configuration/system.web section. Simply add the following XML:
            <httpCookies requireSSL="true" />
The final result will be similar to what you see in the below image:
After saving the file this will apply to everything running in IIS for that front-end – including Service Center and LifeTime. 
Set secure cookies for one or more individual eSpaces (in all the front-ends)
To set secure cookies at the espace level  you need to use the Service Center Factory Configuration component available in the Forge. This will be used to add the same XML setting above, but it will be added to the web.config file of the eSpaces you choose instead of in the global one. This is made through a shared configuration. You can find the XSD template of the shared configuration used and below you can see a screenshot with the configuration settings:

After creating the shared configuration you need to apply it to the eSpaces that require secure cookies. Finally you will need to republish the eSpaces to make the change effective.

Final notes
Secure cookies can be easily implemented in the Agile Platform for .NET, either globally in a front-end or for individual eSpaces using the above instructions.

Finally I would like to thank Miguel João for the initial draft of this document.
If you have any questions or would like to further extend the information in this post feel free to reply.
Acácio Porta Nova
Hi All

I would like to reenforce the fact that if you application has both HTTP and HTTPS flows, using secure cookies can lead to unexpected session loss whenever the user's flow jumps from HTTPS to HTTP, so before activating this setting on all your espaces, confirm that there are no HTTP screens on the application.


Miguel Simões João
Hi all,
OutSystems Platform now supports securing cookies natively. Starting with Platform 9 (Platform Server revision and Platform 8 (Platform Server revision it is now possible to activate the secure cookies setting by changing a setting in the OutSystems Platform.
If you are running the OutSystems Platform on-premises, you can use the instructions below to activate or deactivate this setting. For customers running their platform in the Enterprise Cloud, you can simply request activation of this setting by using the Ask Support option in LifeTime.
Remember that you cannot activate secure cookies unless you have HTTPS configured for your system. If you do not have HTTPS correctly configured, activating this setting will prevent access to any application that requires authentication.
Enable and disable secure cookies for all applications

UPDATED ON 07/02/2017

Factory Configuration now allows you to edit some platform configurations, this being one of them. That being said, there is no longer a need to manually insert or update records on database tables owned by the platform.

 If you want to enable this setting you should install the component, login (the user provider is Service Center), access the 'Platform Configurations' tab and check or uncheck the option 'Secure Session Cookies'.

Ricardo Alexandre Martins

Is the database still the adviced way to go?
or can we set this in a normal fashion now?


more questions:

I have added the sharedConfig to my espace.
however when testing the espace I noticed that osVisit still is not secure...
how come?

Hi J.

The database is still the way to go for this. :)

Regarding the cookie you asked about, that one:
- is not secured by this because it's not a session cookie. 
- that should not be a problem, because that cookie does not enable access to sensitive information.

More about cookies in the platform at