Increasing Security with Per-Customer Subdomains in a Web App
I’m considering adding per-customer subdomains to my web app to enhance security. This would require a wildcard SSL certificate and some additional code. My web app is designed to assist small companies with their cashflow, and initially, customers will not be able to upload their own content.
In terms of security, what advantages does this approach offer? One benefit is the implementation of the Same Origin Policy, which helps prevent cross-domain JavaScript attacks. Are there any other advantages to using per-customer subdomains?
The answer to this question depends on the nature of your application and the level of control your clients have over it. While using subdomains can serve as a security perimeter, there are still some considerations to keep in mind.
Even with the Same Origin Policy in place, users can still make cross-domain requests using Cross Origin Resource Sharing (CORS). If HTTP headers cannot be modified, they may only lose access to the response. However, it is possible for one user to perform a silent file upload to another subdomain without encountering any issues.
Clients may also unintentionally relax the Same Origin Policy. For example, if they can upload files, there is a possibility that someone might upload an allow-all crossdomain.xml file. Additionally, they could set the document.domain to the parent domain, enabling all sibling subdomains to access the DOM.
It is important to note that subdomains do not protect against cookie attacks. Attackers can still set cookies for the parent domain, and other subdomains (belonging to victim clients) would still receive those cookies. To mitigate this risk, separate domains would be necessary.
There are various ways in which applications installed on different domains can communicate with one another, and some of these methods can be exploited for attacks. If you suspect that your clients might attempt to attack each other, it is crucial to implement measures to prevent Cross-Site Request Forgery (CSRF) and Session Fixation. For instance, you can set up different session cookie names for each subdomain and store sessions in a per-client server-side store. Additionally, deny cookies with unknown session IDs.