Comentarios generales. Hay una variedad de arquitecturas, con un nivel diferente de robustez a las vulnerabilidades de seguridad en su código del lado del servidor.
La estrategia más sólida es usar un dominio no relacionado para cada cliente (por ejemplo, customera.com, customerb.com). Esto le brinda todos los beneficios de la política del mismo origen. Por ejemplo:
-
Si un cliente encuentra una forma de cargar Javascript malintencionado en su sitio, no puede atacar a otros clientes (la política del mismo origen del navegador no permitirá que el código malicioso manipule otros dominios).
-
Si el sitio de un cliente tiene una vulnerabilidad de seguridad (por ejemplo, XSS), los atacantes no pueden usarlo como un punto de partida para atacar a sus otros clientes.
Sin embargo, el uso de un dominio no relacionado por cliente hace que pague el costo de un dominio separado por cliente. Es posible que ese costo no sea necesario, dependiendo de su aplicación particular.
La siguiente estrategia más robusta es usar un subdominio diferente por cliente (por ejemplo, customera.mysite.com, customerb.mysite.com). Esto le brinda la mayoría de los beneficios de la política del mismo origen, pero con algunas advertencias y agujeros:
-
Si no tiene cuidado, es posible que el código del sitio de un cliente aún pueda leer las cookies de los sitios de otros clientes. En particular, es importante que todas las cookies establecidas por el sitio para el cliente A tengan su atributo de dominio establecido en customera.mysite.com , no en .mysite.com (como se explica en @dgarcia). Si controla el código del lado del servidor y el código del lado del cliente, puede aplicar esto. Sin embargo, si ejecuta el código provisto por el cliente, puede ser más difícil hacer cumplir este requisito, y es posible que desee utilizar un dominio no relacionado por cliente.
-
No importa cómo configure su sitio, el sitio de un cliente seguirá teniendo la capacidad de establecer cookies para el sitio de otro cliente. Esta es una brecha poco conocida en la política del mismo origen; customera.mysite.com puede configurar una cookie con el atributo de dominio .mysite.com , y luego esa cookie se enviará junto con todas las solicitudes a customerb.mysite.com. (Vea también document.domain para otras vías de ataque). Esta es una posible violación del aislamiento, cuyas implicaciones pueden variar de "ninguna" a "grave". No hay una buena manera de prevenir este vector de ataque. Por lo tanto, si usa un subdominio diferente por cliente, es posible que necesite que el código del lado del servidor esté completamente bajo su control y libre de vulnerabilidades; e igual para todo el Javascript servido en el sitio de cada cliente.
Esta limitación puede ser aceptable en su aplicación o puede que no. Si no es un riesgo aceptable, entonces puede usar dominios no relacionados para cada uno de sus clientes.
La estrategia menos robusta es atender a todos sus clientes desde su mismo dominio (por ejemplo, mysite.com/customera, mysite.com/customerb; o mysite.com con un inicio de sesión diferente por cliente). La desventaja de este enfoque es que ya no puede confiar en la política del mismo origen del navegador para ayudarlo a mantener a los clientes separados, por lo que ahora la responsabilidad pasa a su servidor. No me malinterprete: este enfoque definitivamente puede ser seguro si su código está libre de vulnerabilidades y su código garantiza que ningún cliente pueda atacar a ningún otro. Esta arquitectura es probablemente la más comúnmente encontrada en la web: la mayoría de los sitios web orientados al usuario usan esta arquitectura. La limitación de esta arquitectura es que es menos robusta ante fallas en el código del lado del servidor; un error de XSS, falla de saneamiento u otro problema en su código puede permitir que un cliente ataque a otro, o romper el aislamiento del cliente.
Consejos para su situación particular. Para su aplicación, imagino que cualquiera de estos estaría bien. Parece que no tiene una aplicación de alto valor, por lo que esta no es una situación de alto riesgo y alta sensibilidad. Además, parece que no hay forma de que los clientes carguen contenido, carguen documentos HTML, carguen Javascript, carguen documentos, etc. Esas operaciones son arriesgadas y, si su sitio lo permite, me inclino más a recomendar que use diferentes subdominios dominios no relacionados; pero como su sitio no lo permite, no veo una razón importante por la que necesite dominios diferentes.
Por razones similares, no veo una razón sólida por la que necesite un certificado SSL diferente por cliente. Por lo tanto, sospecho que estaría bien con una arquitectura en la que use un solo dominio y confíe en el código del servidor para autenticar a cada cliente y aplique los controles de acceso adecuados para proteger a los clientes entre sí.