Hi, is there any method to let user change server OPTIONS himself, like PHP and Apache/Nginx options, directives, headers.... there are million options to OPTIMIZE HSTS, cookies, security headers, policies...all for A+ grade of web site, and I simply cannot find out some One-Works-for-All headers, as they need to be individually set in regards what particular domain is using. Policies must be adopted to external resources, fonts, embeded content etc. I know there's security risk involved, as wrong settings might compromise server, but on the other hand, I as admin must take hours and hours of my spare time to just read user suggestions via e-mail, then enter each headers option into CP, test, debug, repair, reapply....it takes ages, and I cannot bill them for this labor, because it is system flaw. I actually do not have real idea, which would resolve all practical and security issues. Maybe as a workaround I would like to see an option to be able to allow user to see and modify server options. So I would enable this for trustworthy and demanding users only. Till, is any plan to resolve the described issue in the future?
This is not just an obscure security risk, the settings on the options tab allow the user to get rid of all limits, access other sites of other customers and take over your server. As you talk about header settings, most of this can be set by the user in his .htaccess file himself directly in the website. But you can allow the user already to set approved configs, that's the way professional hosters are doing it. See System > Directive snippets. There you can define config sets for e.g. specific cms systems which the user can then select in his website settings. And if you want to give users admin permissions (as that's what they have when they are able to modify the server environment themself), then setup a separate vserver for them with ispconfig installed and give them the admin password.
As @till said, there are very significant reasons that users are not allowed to inject arbitrary httpd and php config. Perhaps you could think about improvements to the current interface/approach that could address specific issues you face. We're a small operation, but I haven't had much need from our customers for this, so you might be better suited to know where the best improvements could be made. Eg. one change that might help would be the ability to choose multiple config snippets, rather than only a single one as it is now. For the headers you mention, you could implement a small form to allow users to customize them (though .htaccess works for apache already, and gives customers full control). On your non-billable time, perhaps you could consider a policy of, "I'd be glad to set whatever security headers you need, just email me what you want set for the domain." Then you just cut & paste what they give you, with very little time spent.
@till: thank you, I understand now. But still...setting up separate vserver for one single web site...isn't that resource and setup hog vs. setting up single web site? I've never setup vserver, so I have no idea how it looks like and what impact on my host server it will have. Might it then be the idea to setup vserver for each individual webhosting customer (most of them having 1 web site)? Also NginX is not so friendly like Apache, so config cannot be changed via .htaccess. Any other user controlable option for NginX to optimize, for example, here: https://securityheaders.com/ @jesse: Well, if user has test setup, he'd be able to prepare everything for copy-paste, but in real world that's not a case. User prepares some config suggestion (for NginX, that's the key here!), sends this via email to me, I apply and ...voila! Web page does not work anymore Then I debug, one by one, row by row, analyze, apply repairs etc, because this is way faster than mailing back and forth with the customer. But still it takes me hours to get to perfectly optimized web page to have A+ rating. On Apache customer would be able to implement himself via .htaccess, but on NginX....well, looks like NginX is the obstacle here.
