Headers

general headers play important role in web application security, helping reduce the attack surface against various types of attacks these headers are used in most modern web applications as they provide a basic layer of protection against the most common vulnerabilities passwork docker compose most security headers are applied via the include directive in the main nginx configuration file and are defined in extra/security headers conf strict transport security header is set directly in the main configuration file and thus applies to the entire site header value x frame options "deny" x content type options "nosniff" x xss protection "1; mode=block" referrer policy "strict origin when cross origin" permissions policy "camera=(), microphone=(), geolocation=()" strict transport security "max age=31536000; includesubdomains" apache2\httpd general headers are defined in public/ htaccess they are applied automatically, provided that htaccess processing is not disabled in the apache configuration the strict transport security header is included in the configuration examples in the installation guide header value x frame options "deny" x content type options "nosniff" x xss protection "1; mode=block" referrer policy "strict origin when cross origin" permissions policy "camera=(), microphone=(), geolocation=()" strict transport security "max age=31536000; includesubdomains" x frame options — controls whether the page can be loaded inside a \<frame> , \<iframe> , or \<object> x content type options — prevents browsers from trying to guess the content type (mime sniffing) x xss protection — enables or disables built in xss protection in older browsers deprecated, but may still be used for compatibility referrer policy — defines what information the browser includes in the referer header permissions policy — allows restricting access to various browser features, such as camera, microphone, geolocation, and other apis strict transport security — instructs the browser to load the site only over https, preventing downgrade attacks and mitm cross origin resource sharing cors headers control access to resources from origins other than your own cors headers are only needed if the frontend and backend run on different origins (domain, port, or protocol) passwork docker compose cors headers are configured using the include directive in the main nginx configuration file, with their definitions located in extra/cors conf header value access control allow origin " " access control allow methods "get,head,options,post,put,patch,delete" access control allow headers "authorization, access control allow origin, access control allow headers,origin, accept, x requested with, content type, access control request method, access control request headers, x browser mode, x master key hash, x csrf token" access control max age "1728000" vary "origin" apache2\httpd cors headers are disabled by default you can define them explicitly in the apache virtual host configuration, either inside \<directory> block or globally header value access control allow origin " " access control allow methods "get,head,options,post,put,patch,delete" access control allow headers "authorization, access control allow origin, access control allow headers,origin, accept, x requested with, content type, access control request method, access control request headers, x browser mode, x master key hash, x csrf token" access control max age "1728000" vary "origin" access control allow origin — specifies which domains can make requests to the resource supports the following values allow any origin — specific origin (scheme + domain), e g — https //example com comma separated lists of domains are not allowed by the cors spec and will cause errors multiple domains and other dynamic scenarios are implemented at the web server level passwork docker compose replace the line add header access control allow origin " " always; in the /conf/nginx/extra/cors conf configuration file with the following lines specifying your domains or other pattern part of configuration file cors conf if ($http origin ^https? //(example\\ com|another\\ com)$) { add header access control allow origin "$http origin" always; add header access control allow credentials "true" always; } apache2\httpd add the following block to the virtual host configuration file part of the apache2 virtual host configuration file \<ifmodule mod headers c> setenvif origin "http(s)? //(example\\ com|another\\ com)$" origin allowed=$0 header always set access control allow origin "%{origin allowed}e" env=origin allowed header always set access control allow credentials "true" env=origin allowed header always set access control allow methods "get, post, put, patch, delete, options" env=origin allowed header always set access control allow headers "authorization, access control allow origin, access control allow headers,origin, accept, x requested with, content type, access control request method, access control request headers, x browser mode, x master key hash, x csrf token" env=origin allowed header always set access control max age "1728000" env=origin allowed header always set vary "origin" env=origin allowed \</ifmodule> access control allow methods — specifies which http methods are allowed for cross origin requests access control allow headers — indicates which headers can be included in cross origin requests access control max age — the time (in seconds) for which the results of a preflight request can be cached by the browser, to avoid sending it with every request vary — in the context of cors, used to ensure proper handling of requests on cdns and proxies it allows responses to be cached separately based on different origin values