这取决于应用程序是什么以及客户对它的控制是什么。同源策略仍然适用，因此建议使用子域作为安全边界，但是 - 与往常一样，会有一些怪癖。

您的用户仍然可以使用Cross Origin Resource Sharing进行跨域请求。如果 HTTP 标头无法更改，它们只会失去对响应的访问权限，但是，例如，一个用户可以伪造一个静默文件上传到其他子域而不会出现问题。

您的客户有时也会在不知不觉中放松同源政策。例如，如果他们可以上传文件，很可能有人会上传allow-all crossdomain.xml。此外，他们可以将document.domain设置为父域，以便所有同级子域都可以访问 DOM。

至于 cookie，攻击者仍然可以为父域设置它，而（受害者客户端的）其他子域仍然会获取 cookie，子域不会保护你，只有单独的域可以。

安装在不同域上的应用程序可以通过多种方式相互通信，其中一些方式可用于攻击。如果您怀疑您的客户可能会尝试相互攻击，请特别注意防止跨站点请求伪造（令牌！）和会话固定。例如，为每个子域设置不同的会话 cookie 名称。将您的会话服务器端存储在每个客户端的存储中（即不在公共 /tmp 目录中）并拒绝具有服务器未知会话 ID 的 cookie。

普通的留言。有多种架构，对服务器端代码中的安全漏洞具有不同程度的稳健性。

最稳健的策略是为每个客户使用一个不相关的域（例如 customera.com、customerb.com）。这让您享受同源政策的全部好处。例如：

• 如果一个客户找到了一种将恶意 Javascript 上传到其网站的方法，那么他们就无法攻击其他客户（浏览器的同源策略不会让该恶意代码篡改其他域）。

• 如果一个客户的站点存在安全漏洞（例如 XSS），那么攻击者就不能将其用作攻击您其他客户的起点。

但是，每个客户使用一个不相关的域会使您为每个客户支付一个单独的域的成本。根据您的特定应用程序，可能不需要该成本。

下一个最稳健的策略是为每个客户使用不同的子域（例如 customera.mysite.com、customerb.mysite.com）。这为您提供了同源政策的大部分好处，但有一些警告和漏洞：

• 如果您不小心，一个客户站点上的代码可能仍然能够读取其他客户站点的 cookie。尤其重要的是，网站为客户 A 设置的所有 cookie 都应将其域属性设置为customera.mysite.com，而不是.mysite.com（如 @dgarcia 所解释的那样）。如果您控制服务器端代码和客户端代码，则可以强制执行此操作。但是，如果您运行客户提供的代码，则执行此要求可能会更加困难，并且您可能希望为每个客户使用一个不相关的域。

• 无论您如何配置您的站点，一个客户的站点仍然有权为另一个客户的站点设置 cookie。这是同源政策中鲜为人知的差距；customera.mysite.com 可以设置一个带有域属性的 cookie .mysite.com，然后该 cookie 将与所有请求一起发送到 customerb.mysite.com。（另请参阅document.domain其他攻击途径。）这是一种潜在的隔离破坏，其影响可能从“无”到“严重”不等。没有好的方法可以防止这种攻击媒介。因此，如果您为每个客户使用不同的子域，您可能需要您的服务器端代码完全在您的控制之下并且没有漏洞；对于每个客户网站上提供的所有 Javascript 也是如此。

  这个限制在您的应用程序中可能是可以接受的，也可能不是。如果这不是可接受的风险，那么您可以为每个客户使用不相关的域。

最不健全的策略是为来自同一域的所有客户提供服务（例如，mysite.com/customera、mysite.com/customerb；或 mysite.com，每个客户使用不同的登录名）。这种方法的缺点是您不能再依赖浏览器的同源策略来帮助您将客户分开，因此现在责任转移到您的服务器上。不要误会我的意思：如果您的代码没有漏洞并且您的代码确保没有客户可以攻击任何其他人，那么这种方法绝对仍然是安全的。这种架构可能是网络上最常见的：大多数面向用户的网站都使用这种架构。这种架构的局限性在于它对服务器端代码中的缺陷不太健壮；一个 XSS 错误，清理失败，

针对您的特定情况的建议。对于您的应用程序，我想这些都可以。听起来你没有高价值的应用程序，所以这不是一个高风险高敏感的情况。此外，听起来客户无法上传内容，上传HTML文档，上传Javascript，上传文档等。这些操作有风险，如果您的网站允许，我更倾向于建议您使用不同的子域或不相关的领域；但由于您的网站不允许这样做，我看不出您需要不同域的充分理由。

出于类似的原因，我看不出为什么您需要为每个客户提供不同的 SSL 证书的充分理由。因此，我怀疑您使用单一域并依靠服务器代码对每个客户进行身份验证并应用适当的访问控制来保护客户免受彼此影响的架构会很好。

它还可以防止人们看到和设置彼此的 cookie，而不是让客户处于一个单一的根目录下。在不了解您的应用程序的情况下，很难评估它的重要性。

顺便说一句，通配符证书是危险的——最敏感的盒子只受到最弱的盒子的保护。通配符证书在获得后往往会被大量使用。人们将它们放在邮件服务器、Sharepoint 等上。如果使用得当，它们并不是不安全的，但它们很容易危险地使用，作为政策问题，我避免使用它们。