Thanks. The console of Chromium show me:

"
Content Security Policy blocks inline execution of scripts and stylesheets

The Content Security Policy (CSP) prevents cross-site scripting attacks by 
blocking inline execution of scripts and style sheets.
To solve this, move all inline scripts (e.g. onclick=[JS code]) and styles into 
external files.
Allowing inline execution comes at the risk of script injection via injection 
of HTML script elements. If you absolutely must, you can allow inline script 
and styles by:
adding unsafe-inline as a source to the CSP header
adding the hash or nonce of the inline script to your CSP header.


109 directives
Directive    Element    Source code    Status
script-src-elem        MyWebsite.com/:12    blocked
style-src-elem        MyWebsite.com/:16    blocked
script-src-elem        MyWebsite.com/:53    blocked
script-src-elem        MyWebsite.com/:70    blocked
script-src-elem        MyWebsite.com/:90    blocked
style-src-elem        MyWebsite.com/:95    blocked
style-src-elem        MyWebsite.com/:198    blocked
script-src-elem        MyWebsite.com/:208    blocked
style-src-elem        MyWebsite.com/:218    blocked
style-src-attr        MyWebsite.com/:327    blocked
style-src-attr        MyWebsite.com/:328    blocked
style-src-attr        MyWebsite.com/:332    blocked
style-src-elem        MyWebsite.com/:430    blocked
style-src-attr        MyWebsite.com/:441    blocked
style-src-attr        MyWebsite.com/:444    blocked
style-src-elem        MyWebsite.com/:467    blocked
...
"





On Monday, February 8, 2021, 09:03:41 PM GMT+3:30, James Smith 
<j...@sanger.ac.uk> wrote: 








Without knowing what your website is we can’t really see what is wrong. Have 
you used chrome (or whatever browser you are using) developer’s tools to see 
what is blocked by your content security policy (CSP)

 


From: Nick Folino <n...@folino.us> Sent: 08 February 2021 17:30To: 
users@httpd.apache.orgSubject: Re: [users@httpd] Which parameters must be set 
to solve these Vulnerabilities? [EXT]


 


What a great site!  It consolidates weak servers for hackers to find easier.


 



On Mon, Feb 8, 2021 at 11:00 AM Jason Long <hack3r...@yahoo.com.invalid> wrote:


>  
> Thank you for your useful information.
> I checked my server with "https://securityheaders.com/ [securityheaders.com]" 
> and result is:
> https://i.postimg.cc/SsBBtRsT/Header.png [i.postimg.cc]
> 
> 
> To solve the Content Security Policy, I added below line to "httpd.conf":
> Header set Content-Security-Policy "default-src 'self';"
> 
> But after it my web site style messed up! Why?
> How about "Permissions-Policy" ?
> 
> 
> 
> 
> 
> 
> On Monday, February 8, 2021, 04:58:11 PM GMT+3:30, Dino Ciuffetti 
> <d...@tuxweb.it> wrote: 
> 
> 
> 
> 
> 
>> Hello,
>> I scanned my Apache web server and below Vulnerabilities discovered:
> 
> 
> There are many ways of solving those vulnerabilities. Most of them can be 
> fixed patching your
> applications.
> 
> As rule of thumb, your application should:
> - not use frames or iframes at all
> - use only HTTPS everywhere, always redirect HTTP to HTTPS
> - disable anything you don't need (eg mod_perl, mod_php, etc)
> - enable Strict-Transport-Security to force all traffic to HTTPS with no 
> failback to HTTP
> - don't use cookies if possible, or setup your cookies with those attributes: 
> secure; HostOnly; HttpOnly;
> SameSite=Lax
> - CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be 
> setted directly by your application and not from apache, if possible
> 
> Please consider that enabling one or more countermeasures via configuration 
> file in httpd could make your applications stop working properly if they are 
> not designed accordingly! Please double check any of them and test them in 
> your staging environment before setting them live for production.
> 
> Also you should be well confident in all of them before running live, or 
> strange things will happen to your applications and your live debug will be 
> difficult.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:  users-unsubscr...@httpd.apache.org
> For additional commands, e-mail:  users-h...@httpd.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:  users-unsubscr...@httpd.apache.org
> For additional commands, e-mail:  users-h...@httpd.apache.org
> 


-- The Wellcome Sanger Institute is operated by Genome Research Limited, a 
charity registered in England with number 1021457 and a company registered in 
England with number 2742969, whose registered office is 215 Euston Road, 
London, NW1 2BE. 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Reply via email to