4

We are currently in the process of converting our multiple codebases (which are exactly the same, except for a configuration file and 2 stylesheets).

We have been thinking about this for a while, and the idea for now is to determine the domain the user is accessing and loading the stylesheets and configuration file depending on the domain.

For example:
User 'A' goes to the website 'www.my.example.com' and the configuration (which includes database, SMTP and other options) and the stylesheets get used. We determine everything depending on their domain.

So if user 'B' goes to the other CMS 'my.exampler.com' it will load the configuration and stylesheets for 'my.exampler.com' instead of 'my.example.com'.

Are there any security risks as to doing it this way? We currently do not know of any possible security risks which could occur. The configuration file is not accessible for users without having FTP or direct access to the server itself.

Is this a bad idea? Is there possibly a more secure way to do this? Or is this an acceptable way to create a single codebase for every CMS?

  • You mean single copy of source code for multiple websites? What about database, is there only one database? In case one website is breached, and all configuration is stolen, access to all databases is then granted to attacker. – Aria Jan 2 '18 at 15:03
  • @Aria Database related data is stored separately and passwords differ between each of them, we load a configuration file depending on the domain. So if a website gets breached, they only have access to the subfolder of that domain due to root restrictions – pandaJuan Jan 2 '18 at 15:08
  • It seems you want something similar to wordpress multisite: codex.wordpress.org/Create_A_Network – jrtapsell Jan 2 '18 at 16:06
1

In the abstract, serving multiple domains from a single codebase is far better than serving multiple domains from multiple codebases. Less code much better than more code.

That said, there are reasons NOT to do this- most notably if the different domains have different risk profiles (like one is a CMS and another is ecommerce).

And when doing this, it has to be done with care. One common mistake is to implicitly trust the incoming Host header and reuse it in templates and so forth, which opens all of the sites hosted in this way to compromise.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.