Website Security Test

HTTP Strict Transport Security (HSTS) Policy Not Implemented

LOW

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

It's recommended to implement HTTP Strict Transport Security (HSTS) into your web application. Consult web references for more information

Referrer-Policy Header Not Implemented

INFORMATIONAL

The Referrer-Policy HTTP header controls how much referrer information (sent via the Referer header) should be included with requests. Mozilla The Referer (sic) header contains the address of the previous web page from which a link to the currently requested page was followed, which has lots of fairly innocent uses including analytics, logging, or optimized caching. However, there are more problematic uses such as tracking or stealing information, or even just side effects such as inadvertently leaking sensitive information.

Configure your server to send the Referrer-Policy header for all pages with the value set to strict-origin-when-cross-origin. You can see references for other possible values.

X-Frame-Options Header Not Implemented

LOW

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.

Configure your server to send this header for all pages. You can see references for possible values.

X-Content-Type-Options Header Not Implemented

INFORMATIONAL

The X-Content-Type-Options response HTTP header is used by the server to prevent browsers from guessing the media type ( MIME type). This is known as MIME sniffing in which the browser guesses the correct MIME type by looking at the contents of the resource. The absence of this header might cause browsers to transform non-executable content into executable content.

Configure your server to send this header with the value set to nosniff.

X-XSS-Protection Header Not Implemented

INFORMATIONAL

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Chrome has removed their XSS Auditor Firefox has not, and will not implement X-XSS-Protection Edge has retired their XSS filter This means that if you do not need to support legacy browsers, it is recommended that you use Content-Security-Policy without allowing unsafe-inline scripts instead.

Do not send this header or set 0 as value.

Permissions-Policy header Not Implemented

INFORMATIONAL

The Permissions-Policy header allows developers to selectively enable and disable use of various browser features and APIs.

Configure Permission Policy Header properly

Robots.txt file Found

INFORMATIONAL

The file robots.txt is used to give instructions to web robots, such as search engine crawlers, about locations within the web site that robots are allowed, or not allowed, to crawl and index. The presence of the robots.txt does not in itself present any kind of security vulnerability. However, it is often used to identify restricted or private areas of a site's contents. The information in the file may therefore help an attacker to map out the site's contents, especially if some of the locations identified are not linked from elsewhere in the site. If the application relies on robots.txt to protect access to these areas, and does not enforce proper access control over them, then this presents a serious vulnerability.

The robots.txt file is not itself a security threat, and its correct use can represent good practice for non-security reasons. You should not assume that all web robots will honor the file's instructions. Rather, assume that attackers will pay close attention to any locations identified in the file. Do not rely on robots.txt to provide any kind of protection over unauthorized access.

X-Permitted-Cross-Domain-Policies is Not Implemented

INFORMATIONAL

This header is used to limit which data external resources, such as Adobe Flash and PDF documents, can access on the domain. Failure to set the X-Permitted- Cross-Domain-Policies header to “none” value allows other domains to embed the application’s data in their content.

If there is no requirement to load application data within web clients such as Adobe Flash Player or Adobe Acrobat (not limited to these), then the header should be configured as follows. X-Permitted-Cross-Domain-Policies: none

OPTIONS Method Enabled

INFORMATIONAL

AWASAF detected that OPTIONS method is allowed. This issue is reported as extra information. Information disclosed from this page can be used to gain additional information about the target system.

Disable OPTIONS method in all production systems.

Cookie without HttpOnly flag set

LOW

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive. You should be aware that the restrictions imposed by the HttpOnly flag can potentially be circumvented in some circumstances, and that numerous other serious attacks can be delivered by client-side script injection, aside from simple cookie stealing.

TLS cookie without secure flag set

LOW

If the secure flag is set on a cookie, then browsers will not submit the cookie in any requests that use an unencrypted HTTP connection, thereby preventing the cookie from being trivially intercepted by an attacker monitoring network traffic. If the secure flag is not set, then the cookie will be transmitted in clear-text if the user visits any HTTP URLs within the cookie's scope. An attacker may be able to induce this event by feeding a user suitable links, either directly or via another web site. Even if the domain that issued the cookie does not host any content that is accessed over HTTP, an attacker may be able to use links of the form http://example.com:443/ to perform the same attack. To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.

The secure flag should be set on all cookies that are used for transmitting sensitive data when accessing content over HTTPS. If cookies are used to transmit session tokens, then areas of the application that are accessed over HTTPS should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications.

HTTP PUT method is enabled

HIGH

The HTTP PUT method is normally used to upload data that is saved on the server at a user-supplied URL. If enabled, an attacker may be able to place arbitrary, and potentially malicious, content into the application. Depending on the server's configuration, this may lead to compromise of other users (by uploading client-executable scripts), compromise of the server (by uploading server-executable code), or other attacks.

Disable the HTTP PUT method on the server.

Misconfigured Access-Control-Allow-Origin Header

MEDIUM

CORS (Cross-Origin Resource Sharing) defines a mechanism to enable client-side cross-origin requests. This application is using CORS in an insecure way. The web application fails to properly validate the Origin header (check Details section for more information) and returns the header Access-Control-Allow-Credentials: true. In this configuration any website can issue requests made with user credentials and read the responses to these requests. Trusting arbitrary origins effectively disables the same-origin policy, allowing two-way interaction by third-party web sites

Allow only selected, trusted domains in the Access-Control-Allow-Origin header.

.htacces File Detected

INFORMATIONAL

This directory contains .htaccess file that is readable.This may indicate a server misconfiguration. htaccess files are designed to be parsed by web server and should not be directly accessible . These files could contain sensitive information that could help an attacker to conduct further more attacks.It is recommended to restrict access to these files

Restrict access .htaccess files by adjusting the web server configuration

Out-of-date Version (Apache)

INFORMATIONAL

AWASAF identified you are using an out-of-date version of Apache.

Please upgrade your installation of Apache to the latest stable version. Since this is an old version of the software, it may be vulnerable to attacks.