Setting and storing session ID securely in Static sites

I’m using API Form Response data to set session id for users to keep them logged in. I read that storing it in HTTP Only cookie will help prevent third party scripts on my page from reading this information.

However i also read that this is only true if javascript is not used to set or read this cookie.
I’m using the ‘cookie.set’ action to set the cookie from response data of API Form. Does this mean I’m using javascript behind the scenes to set the cookie and reducing the security of the cookie.

What really is the best way and place in Wappler Static sites to store sensitive data like session id ?

I just a beginner to website development and reading about the many security problems is confusing. If anyone could please tell me what is the best i could do within Wappler for my use case, it would be a big help. Thanks

@Teodor Please can you help, i’m feeling very worried about this . Sorry to bother you

HTTP Only cookies work only with cookies send from the server and cannot be set with javascript. With javascript there is not a 100% secure way to store data that 3rd party scripts can’t access also.

Having 3rd party scripts in your website can always be a security risk, it is to make sure that you trust the 3rd party. When possible you could host the scripts yourself or with modern frameworks like bootstrap they offer an integrity check, adding that on the script include will prevent it to load the script when the integrity fails (man in the middle attack or when someone somehow replaced the source).

When you trust the scripts included in your page then it is safe to set the cookie using javascript or storing the session id in localstorage or sessionstorage.

Does the DMX App connect also have an integrity check option ? Or is that unneccesary

And between localstorage and cookies , even if both are not completely secure, which of these is more secure . This is the action that is run on Login API Form Dynamic Event “done” and I’m confused if there is any advantage to using cookie here

I also read about cookies being sent with every request and I’m not sure what “request” means.
I will need to use session Id (stored in the cookie or local storage) to call my APIs like
Update Profile, Reset Password (using API Action).
These apis are hosted on mysite.azurewebsites.net

Lastly, Sorry if this is a stupid question, but i will be directing logged in users to content like mysite/content/game1 , mysite/content/game2
which is content hosted on a CDN. Does this mean cookies will be sent to the cdn?

The integrity check is mostly with content hosted on a CDN (external domain/server), the App Connect script is normally hosted on your own server.

Localstorage and sessionstorage would be the better one, cookies are also being send to the server and for a static website that is not needed. Localstorage doesn’t expire, so the session id will be stored until you delete it. The sessionstorage will keep the session id until the tab is being closed, other tabs cannot access the session id while with localstorage the session id is shared with all tabs.

Both cookies and sessionstorage are domain specific, when redirecting to a different domain they will not be accesable anymore.

<script src="../dmxAppConnect/dmxAppConnect.js"></script>

Ok So this means dmxappConnect actually hosted the same place that mysite is hosted and i don't need the integrity

Sorry but last question
I have the option of hosting my my Azure Functions API on a custom domain.
so instead of mysite.azurewebsites.net
this mysite.com/api
In this case will cookies have any security advantage
And i will this API from API Form or API Action

Thanks a lot

After reading a few more times , from what I understand
HttpOnly is what protects the cookie from third party scripts accessing the data, but as this is not possible in static site cookie has no advantage to me.

So i will use session storage. Thank you very much Patrick and Teodor

The HttpOnly protects the cookie from being accessed by JavaScript, it can only be accessed with server-side scripts.

1 Like