After I did that I came along the new Health Check in the Panel.
So I’ve got 3 Error Messeges wich tell me that the site, content and kirby folder are probably exposed. I clicked on the messege and got directed to kirby’s security checklist wich tells me that there is maybe something wrong with my .htaccess.
I checked that and everything matched perfectly with the »vanilla-htaccess« (included in the plain kit). Then I tried out all the url checks
(e.g. http://www.yoursite/content/site.txt) and always got, like expected, redirected to the errorpage.
So I think everything is alright but I still have there errors in the Health check.
Any Idea how to fix this or how kirby checks the folder/file permissions?
I get »Running system health checks for the Panel system view; failed requests in the following console output are expected behavior«
and »System health checks ended.«
Which is not surprising in my case, because my local system runs on Laravel Valet with Nginx, so the .htaccess is of no use and I haven’t bothered fixing the Valet Nginx configuration.
Kirby checks those URLs that are shown in the console screenshot I posted above. It seems that they are accessible. Guess the URLs itself are only shown when debugging is enabled for security reasons.
Do you get the same result with a fresh Starterkit on your server?
I guess you could return a 404 directly from your htaccess instead of sending those request through Kirby’s router. But Kirby’s router should return a 404 for those requests, not a 302. So wondering if you have any routes in place that return the 302.
I found a solution wich is most likely a workaround.
And I think at some point I have to make a new installation of kirby to fix all those permission errors. I’m not the owner of the server it’s always a bit tough though.
So my solution was to block all folders with a custom .htaccess wich includes a simple
Deny from all
when I try to access the files/folders directly with the url
(e.g. http://www.yoursite/content/site.txt) it throws an classic 403 error
instead of redirecting to the errorpage.
Anyway. Now I get the expected 403s and no Security Issues are shown.