Well first of all remember that in order to use the header() function, you canât send any kind of markup or headers before its use. So for instance you canât send along the DOCTYPE and then try to use header(). Otherwise you will get a message like âheaders already sentâ. Try visiting the page directly first before running it through that tool and make sure you are not getting that error.
Try moving the header() call above the rest of the content so that it is the first line of the script and see if that helps.
If you check out the header() function help page, you will notice that you may need to call header() for each separate header, not chain them together in one.
I donât think you can chain them all together in a single call. As for the hash, that is really only used for inline scripts. So unless you have some inline JavaScript, you can probably skip that piece for now. If you have inline scripts, then this article can quickly get you started to show you how to put them inâŚ
I have a last (I hope) problem: some scripts donât work if I remove (from script-src) 'unsafe-inline' https: (as required to avoid a âhigh severityâ risk).
How could I both avoid the risk and keep that (inline) scripts?
You canât. Inline scripts open you up to Cross Site Scripting which is why itâs highly discouraged.
So either move all JavaScript to separate js files that are included in the HTML, or keep âunsafe-inlineâ in the CSP. There is no middle ground here.
Maybe someone should mention that CSP is a tool to fix failures you have done before. If your code is good you do not need CSP at all. Because you cannot know that your code is 100% secure it may help to use CAP anyways.
But You are trying to use CSP to secure Bad code and thatâs not the right attempt
Thatâs like saying if your house is never on fire you donât need fire insurance.
You can and should still use CSP even if you think your site doesnât have any flaws. One small flaw is enough to take down the site, so itâs nice to have counter measures in place. Especially when theyâre as easy to configure as CSP.
I agree on that. Altough CSP can be a good idea to show you where the pain points are that need to be fixed.
To be honest when I started developing with PHP (over 15 years ago) I did exactly the same like you do now. I put everything mixed up in one file. Html, javascript, php and sometimes also css. This was the fastest way to create an application which did what I want.
For luck none of these apps were really important and only for my personal use. So it would have been not a big deal if they would have been hacked.
Today developing software is much more strict and therefor much more complicated to learn. But at the end you need to understand how all this is working together and grabbing into each other, without mixing it and have deep dependencies.
So yes, the onClick in the php code is no longer good style. You need a separate JavaScript file which is adding an event handler to the Dom element you want to listen too.
At the end I would also suggest to no longer use PHP as a frontend creater. I would not even suggest to use PHP at all when someone asks me in what language he should write web applications. There are many JavaScript frameworks if you want one (you can also write completly in vanilla JavaScript) for the frontend part and there are many nice backend languages like nodejs, python or even dot.net or spring boot.
Learning PHP nowadays is for me like being on a wrong (dying) horse.
The code in and of itself isnât unsafe. Itâs not a good practice, as @Thallius points out, but itâs not inherently unsafe.
Whatâs unsafe is that in order for it to be usable you need to allow inline scripts on your website. So if someone manages to get their malicious script on your website somehow, e. g., by posting a comment with Javascript in it, or a carefully crafted search, stuff like that, then that code will be executed too, as the browser canât differentiate between legit and non legit code and will just execute all of it.
If you donât allow inline scripts than no inline scripts will be executed by the browser at all. So even if someone gets their malicious Javascript on your site, it wonât get executed.
For more info please refer to my link to Cross Site Scripting a few posts above.
Thank you, @Thallius and @rpkamp.
In my websites I donât have forum, nor comments of readers, or search form.
I will try, any way, to convert that inline js in what you suggest.