Several technical questions about Cookies, Subresource Integrity (SRI), etc

A customer came to us with numerous technical questions/requirements. Can anyone answer them?

  1. The SRI (Subresource Integrity) mechanism MUST be implemented for CSS or Javascript resources when they are hosted outside (e.g. resource hosted on a CDN or by a partner).
    How can we implement SRI? May be there is a configuration option in servoy.properties?

  2. All cookies SHOULD be protected by “httpOnly”, ‘Secure’ and “SameSite” attributes.
    Is this done by Servoy Framework?

  3. Cookies representing an application session or a user’s authentication token MUST be protected by the “httpOnly” and “Secure” attributes.
    Is this done by Servoy Framework?

  4. Cookies representing an application session or a user’s authentication token SHOULD be protected by the “SameSite” attribute. The choice of the “strict” or “lax” option should be discussed with the security department, on an application-by-application basis.
    Is this done by Servoy Framwork?

  5. The technical element that represents a user’s security context MUST be systematically verified by any application that uses it.
    Does someone understand this?

Thank you.
Best regards,
Monika

this is default done in a deployment of a TiNG client, all the javascript and css that belongs to the TiNG client (angular code) has stuff like:

integrity=“sha384-wHncSybpfmIyhwkspUP26tPT6pysK/CzIScfamAIbsRVsQPy/a0XDOOgGFhUHJj1”

the pure dynamic things (like solution css) don’t have that

Besides that all that stuff including that now already done with SRI is not hosted outside.. its all coming from the main server (our WAR). And for TiNG there is almost nothing anymore that comes from outside (at least not our core and all our basic components)
Of course stuff like Google Maps downloads stuff from google, and those downloads are dynamic and handles by the google lib. so not in our control.

We only have by default the http session cookie, that has httpOnly and secure (if coming from https if tomcat sees that) set. SameSite can be configured if needed by a tomcat.xml file that you can add to the WAR.

the stateless login does set a csrf_token cookie which is httpOnly and that is only used until the login (to not let them login through another site) after login this cookie has no meaning.
It is not directly secure because we don’t really know that that is possible (we can’t always see if you really are behind a https if https is handles by another server)

Of course there can be other cookies like a load balance cookies if you deploy in servoy cloud or your self in azure or amazon, but then you need to talk to the load balance stuff to see if they can set those cookies all correct. (mostly they do)

this is the http session cookie so yes.

also the same as above.

This means if you access a server from the outside the user should be checked again, the thing is servoy code is purely server side and that is logged in or not, and that is based on a websocket not a http get or post request.
So all stuff that are requested do come to a authenticated ngclient instance at the server because we are statefull, and that session is a combination of an id (just a number) that is stored in the current window and the http session id.

Thank you very much, Johan, for the detailed answers. They help us a lot for our answers to the customer.