I'm thinking about adding per-customer subdomains to my web app (which would mean a wildcard ssl certificate and some extra code). It's an app to help small companies with their cashflow. Customers won't be able to upload their own content to the app, at least not at the beginning.
What does it bring in terms of security? For instance, my understanding is that I will benefit from the same origin policy to avoid cross-domain javascript. Is it actually the case, and are there other benefits?
It depends on what the application is and what are clients' control over it. Same Origin Policy still applies, so it's advisable to use the subdomain as a security perimeter, but - as always, there will be some quirks.
Your users can still do cross-domain requests with Cross Origin Resource Sharing. If HTTP headers can't be changed they would only lose access to the response, but, for example, one user could fake a silent file upload to other subdomain without problems.
Your clients could also, sometimes unknowingly, relax Same Origin Policy. For example if they can upload files, most likely someone would upload allow-all crossdomain.xml. Also, they could set document.domain to the parent domain so that all sibling subdomains could access the DOM.
As for cookies, attacker can still set it for the parent domain and other subdomain (of victim client) would still get the cookie, subdomains won't protect you from that, only separate domains would.
There are many ways applications installed on different domains could communicate with each other, some of these ways can be used for an attack. If you suspect your clients might try attacking each other, pay special attention to prevent Cross Site Request Forgery (tokens!) and Session Fixation. For example set up different session cookie name for every subdomain. Store your sessions server-side in a per-client store (i.e. not in common /tmp directory) and deny cookies with session ID that is unknown to the server.
General comments. There are a variety of architectures, with a differing level of robustness to security vulnerabilities in your server-side code.
The most robust strategy is to use an unrelated domain for each customer (e.g., customera.com, customerb.com). This gets you the full benefits of the same-origin policy. For instance:
If one customer finds a way to upload malicious Javascript onto their site, then they cannot attack other customers (the browser's same-origin policy won't let that malicious code tamper with other domains).
If one customer's site has a security vulnerability (e.g., XSS), then attackers cannot use it as a jumping-off point to attack your other customers.
However, using one unrelated domain per customer makes you pay the cost of a separate domain per customer. That cost may not be necessary, depending upon your particular application.
The next-most robust strategy is to use a different subdomain per customer (e.g., customera.mysite.com, customerb.mysite.com). This gets you most of the benefits of the same-origin policy, but with some caveats and holes:
If you're not careful, code on one customer's site may still be able to read cookies from other customers' sites. In particular, it is important that all the cookies set by the site for customer A should have their domain attribute set to customera.mysite.com, not .mysite.com (as explained by @dgarcia). If you control the server-side code and client-side code, you can enforce this. However, if you run customer-supplied code, it may be harder to enforce this requirement, and you may want to go with an unrelated domain per customer.
No matter how you configure your site, one customer's site will still have the power to set cookies for another customer's site. This is a little-known gap in the same-origin policy; customera.mysite.com can set a cookie with domain attribute .mysite.com, and then that cookie will be sent along with all requests to customerb.mysite.com. (See also document.domain for other attack avenues.) This is a potential breach of isolation, whose implications may vary from "none" to "serious". There is no good way to prevent this attack vector. Therefore, if you use a different subdomain per customer, you may need your server-side code to be entirely under your control and be free of vulnerabilities; and the same for all Javascript served on each customer's site.
This limitation might be acceptable in your application, or it might not. If it is not an acceptable risk, then you can use unrelated domains for each of your customers.
The least robust strategy is to serve all of your customers from your same domain (e.g., mysite.com/customera, mysite.com/customerb; or mysite.com with a different login per customer). The downside of this approach is that you can no longer rely upon the browser's same-origin policy to help you keep customers separate, so now the responsibility passes to your server. Don't get me wrong: this approach can definitely still be secure if your code is free of vulnerabilities and your code ensures that no customer can attack any other. This architecture is probably the most commonly found on the web: most user-facing websites use this architecture. The limitation of this architecture is that it is less robust to flaws in your server-side code; a XSS bug, failure of sanitization, or other problem in your code can enable one customer to attack another, or breach customer isolation.
Advice for your particular situation. For your application, I imagine that any of these would be fine. It sounds like you do not have a high-value application, so this is not a high-risk high-sensitivity situation. Moreover, it sounds like there is no way for customers to upload content, upload HTML documents, upload Javascript, upload documents, etc. Those operations are risky and if your site allowed them, I would be more inclined to recommend you use different subdomains or unrelated domains; but since your site doesn't allow that, I don't see a strong reason why you need different domains.
For similar reasons, I don't see a strong reason why you need a different SSL certificate per customer. Therefore, I suspect you would be just fine with an architecture where you use a single domain and rely upon the server code to authenticate each customer and apply appropriate access controls to protect customers from each other.
It also prevents people from seeing and setting cookies for each other, as opposed to having the customers under a single root. Hard to evaluate how important that is without knowing your app.
By the way, wildcard certificates are dangerous - the most sensitive box is only as protected as the weakest. Wildcard certs tend to get used a lot after you get them. People put them on mail servers, Sharepoint, etc. They're not insecure if used properly, but they're quite a temptation to use dangerously, and as a matter of policy, I avoid them.
