This paper investigates whether security headers are enforced to mitigate cyb er-attacks in web-based systems in cyberspace. The security headers examined include X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Referrer-Policy, Content-Security-Policy, and Permissions-Policy. The study employed a controlled experiment using a security header analysis tool. The web-based applications (websites) were analyzed to determine whether security headers have been correctly implemented. The experiment was iterated for 100 universities in Africa which are ranked high. The purposive sampling technique was employed to understand the status quo of the security headers implementations. The results revealed that 70% of the web-based applications in Africa have not enforced security headers in web-based applications. The study proposes a secure system architecture design for addressing web-based applications’ misconfiguration and insecure design. It presents security techniques for securing web-based applications through hardening security headers using automated threat modelling techniques. Furthermore, it recommends adopting the security headers in web-based applications using the proposed secure system architecture design.
Security headers adoption and implementation have raised attention on how they are fused in web-based systems security design. Its enforcement in combination with security web applications technologies’ best practices [
Security precautions are not defined in security header response parameters in web-based systems. This results in security holes/weaknesses or threats to web-based systems. These vulnerabilities can be eliminated, minimized, or corrected by implementing security headers [
Web-based applications are developed without incorporating security headers during system design; leaving the system vulnerable to attacks. Injection flaws (such as cross-site scripting, and SQL injections) are introduced during system design; cannot be fixed during systems implementations. The security controls that are not defined during system design leave the system vulnerable to cyber-attacks. The insecure design is contributed by ineffective or lack of business profiling using automatic threat modelling tools during the systems development lifecycle. This led to the failure to determine the optimal level of system security design required to withstand various cyber-attacks. The insecure design gap is widened by misconfigurations of the secure web applications technologies’ best practices such as hardening security headers in information systems. It introduces security holes, dangerous gaps, or mistakes that leave the system open to cyber attacks.
This study aims to investigate the security headers implementations landscape in web-based information systems in Africa’s top 100 Universities/Colleges, and proposes a secure web-based system architecture design using threat modelling techniques.
Security headers introduce another additional layer of security for preventing cyber-attacks such as cross-site scripting [
X-XSS protection security header is responsible for protecting against cyber-attacks such as Cross-Site Scripting attacks [
The Content Security Policy (CSP) header implements an additional layer to prevent web-based attacks [
The X-Frame-Options HTTP response header is used to indicate if a browser is permitted to execute a page [
The X-Content-Type-Options header provides an option for disabling MIME-type sniffing in web-based applications. MIME-type sniffing is the functionality of a web browser to inspect web contents to determine the file type format for uploaded files from users. This functionality can be misused to execute XSS attacks [
A Strict Transport Security header (HSTS) forces browsers only to be accessed through HTTPS protocol instead of HTTP [
A study by [
The study employed a controlled experiment using an automated security header analysis tool. The web-based applications (websites) were analyzed for whether security headers have been correctly implemented. The experiment was iterated for 100 universities in Africa [
The study sample was selected using purposive sampling. The purposive sampling technique was employed to get a depth understanding [
The data analysis was done using a controlled experiment that involved the analysis of web-based applications/websites for 100 top-ranked universities in Africa. The analyzed HTTP response headers and rated web-based systems were rated into F, E, D, C, B, A and A+; where F is the lowest; and A+ is the highest. The score rating of F means that an institution has not implemented security headers in the given system; E to B means that an institution has implemented some of the security headers in the given web-based application/website. Score A or A+ means that institution has implemented most of the required security headers. A security rating score of D to F implies that a given website/web-based application is open to cyber-attacks such as cross-site scripting, SQL injections, and session hijacking.
The following materials were prepared for conducting the controlled experiment for:
1) List of web-based applications/websites for institutions in Africa;
2) Laptop with Intel Core i7 processor, 2.3 GHz, 16 GB RAM, 64-bit processor, Windows 10 Pro. with Internet connectivity;
3) Security headers analysis tool [
The experiment aimed to evaluate the security of web-based applications/websites using a security header security analysis tool; a case study of higher learning institutions. The top 100 ranked universities in Africa were considered for this study.
The study analyzed security headers for a given website/web application to determine whether security headers have been implemented or not. The security headers responses for Strict-Transport-Security Referrer-Policy, X-Frame-Options, Content-Security-Policy, Permissions-Policy, and X-Content-Type-Options security headers were recorded.
The given website or web application was analyzed to determine the security level and readiness implementations of security headers. The experiment was executed in circular fashion iterations for 100 universities. The results are presented in table form for each security header employed in the experiment. The results are presented in section 4.
This section presents results findings for analysis of security in web-based applications for the top 100 universities, colleges, and higher learning institutions in Africa. The results and their discussions are presented for 6 security headers; namely: X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Referrer-Policy, Content-Security-Policy, and Permissions-Policy as follows.
The results for security header analysis of misconfigurations of security header: X-Content-Type-Options were carried out for 100 top-level universities in Africa. The results revealed that 70% of the web-based applications in Africa have not been correctly configured. The content-Type-Options security header is shown in
MIME sniffing is used by some web to examine the content of a particular asset. This can cause security risks by allowing attackers to send an XSS (Cross-Site Scripting) attack. To stop this vulnerability set X-Content-Type-Options: nosniff in the web-server configuration file. This will force the browser to disable MIME sniffing and stop analyzing MIME type) and use the correct MIME type which is sent by the server hosting the application.
The results revealed that 70% of the web-based applications in Africa have not
X-Content-Type-Options | % |
---|---|
No | 70 |
Yes | 30 |
correctly configured the X-Frame Options security header as shown in
The results revealed that 90% of the web-based applications in Africa (Tanzania inclusive) have not correctly configured the X-Frame Options security header as shown in
The results revealed that 96% of the web-based applications in Africa (Tanzania inclusive) have not correctly configured the X-Frame Options security header as shown in
The results revealed that 96% of the web-based applications in Africa (Tanzania inclusive) have not correctly configured the content security policy security header as shown in
X-Frame-Options | % |
---|---|
No | 70 |
Yes | 30 |
Strict-Transport-Security | % |
---|---|
No | 90 |
Yes | 10 |
A Referrer Policy | % |
---|---|
No | 96 |
Yes | 4 |
Content-Security-Policy | % |
---|---|
No | 96 |
Yes | 4 |
Permissions Policy | % |
---|---|
No | 100 |
Yes | 0 |
configured with a content security policy security header.
The results revealed that 100% of the web-based applications in Africa (Tanzania inclusive) have not correctly configured the content security policy security header as shown in
The study proposes a secure web-based architecture design; it comprises of secure web browser (for the clients), a secure web server, and threat modelling automatic system integration as shown in
The descriptions of components of secure web-based architecture design are as follows:
1) Security threat modelling
This assists to highlight design faults that leave the systems vulnerable to cyber-attacks. Among these security threat modelling frameworks/models are STRIDE, PASTA, TRIKE, VAST, DRED, and OTAVE. The steps in security threats modelling for secure web-based design are: step 1-Diagram the application:
break down the system into components and visualize using process flows showing interactions, actors, and protocols involved. Step 2: identify the assets to be protected. Step 3: identify the various threats affecting each identified asset based on system components. Step 4: assess risks: business risks profiling; risks are defined based on the threats affecting assets for the information system. Step 5: mitigate the threats/risks: the risks are mitigated throughout the system development lifecycle based on business risk profiling; this results in a secure system design architecture. Step 6: validate the threat model: by using automated tools [
2) Security requirements and security controls
Define security controls [
3) Harden system security
This involves hardening the information system based on the defined security controls through threat modelling. Security headers and other security controls are correctly configured according to security requirements in an iterative fashion until the secure system’s optimal level is reached.
4) Security headers configuration
The configurations of security headers are based on security requirements for the given web-based application; its description is as follows.
a) X-content-Type-option
{X-Content-Type-Options: nosniff}
The X-Content-Type-Options should be set to “nosniff to mitigate MIME sniffing in the client web browser. This mitigates the exploitation of data in response to requests from the web server while clients access resources from the web server. Its exact syntax slightly varies from one operating system’s distribution to another.
b) X-Frame-Options
The X-Frame-Options security header is used to indicate whether or not a web-based application accessed via the browser by the client should be allowed to render a web page in a “frame” or when “iframe” is employed. Web applications use this security header to protect against Clickjacking attacks [
c) Strict-Transport-Security
HTTP Strict transport security header (HSTS) forces the web-based application to be accessible only through HTTPS connections [
Syntax:
Strict-Transport-Security: max-age=
Strict-Transport-Security: max-age= ; includeSubDomains
Strict-Transport-Security: max-age= ; preload
For example:
{Header set Strict-Transport-Security: max-age = 31,536,000; includeSubDomains; preload}
max-age =“expire-time”: The time (in seconds) the browser should remember the web-based application is accessible through HTTPS only.
includeSubdomains: this is the option; when is set it implies that this rule applies to all the domain and their subdomains for a web-based application.
Preload (option):This directive enables the owner of the web-based application to directly preload their domains and their subdomains. It leads to privacy violations of cookie values; login cookies are leaked. Preloading has some usability limitations: removing subdomains added in error takes time as you should wait for removal to complete its propagation; changing the max-age directive is possible after the original specified maximum age time expires; some systems use only http; when all sub-domains are forced to HTTPS, it can cause usability challenges.
d) Referrer-Policy: {Keywords: *, none, self, hosts}
The Referrer-Policy security header controls the amount of referrer information which are sent through the Referrer-Policy security header with each request in web-based applications.
Referrer-Policy:strict-origin-when-cross-origin
e) X-XSS-Protection: {Header set X-XSS-Protection “1; mode = block”}
X-XSS protection security header is protecting web-based applications against cyber-attacks such as Cross-Site Scripting attacks. The optimal configuration for the X-XSS protection header has changed from blocking (X-XSS auditor has been removed in modern browsers like Chrome, and Edge); other browsers like Firefox have not implemented X-XSS protection.
Syntax: {
X-XSS-Protection: 0; X-XSS-Protection: 1; X-XSS-Protection: 1; mode=block; X-XSS-Protection: 1; report= }
f) Permissions-Policy
The referrer (or “referrer”) header is sent to a server when you visit a website and were previously on another website. The target site can use that header to see where you came from.
Syntax:
{Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-URL
}
no-referrer: The Referer header is excluded: sent requests do not include any referrer information.
no-referrer-when-downgrade: Send the origin, path, and query string in Referer when the protocol security level stays the same or improves (http→hhtp; http→https; https→https). Referer headers are not sent to the less secure endpoint for web-based requests (https→http; https→file).
The descriptions of these descriptive:
origin: Send only the origin in the Referer header. For example, a document at https://example.com/page.html will send the referrer to https://example.com/.
origin-when-cross-origin: When performing a same-origin request to the same protocol level (HTTP → HTTP, HTTPS → HTTPS), send the origin, path, and query string. Send only the origin for cross-origin requests and requests to less secure destinations (HTTPS → HTTP).
same-origin: Send the origin, path, and query string for same-origin requests. Don’t send the Referer header for cross-origin requests.
strict-origin: Send only the origin when the protocol security level stays the same (HTTPS → HTTPS). Don’t send the Referer header to less secure destinations (HTTPS → HTTP).
strict-origin-when-cross-origin (default):Send the origin, path, and query string when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays the same (HTTPS → HTTPS). Don’t send the Referer header to less secure destinations (HTTPS → HTTP).
For enhancing security, the recommended optimal configuration for Referer header-policy security header is set as Referrer-Policy:strict-origin-when-cross-origin. It tells the referrer header to not send referrer information to any user who visits another server.
The findings reveal that security headers in web-based systems are not taken into consideration during the systems development life cycle. This has been shown in the analysis survey of web-based applications in the top 100 websites of universities in Africa (Tanzania inclusive). The security headers included in this survey analysis using a web-based security header analysis tool are X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Referrer-Policy, Content-Security-Policy, and Permissions-Policy. The results revealed that most of the web-based systems in cyberspace have not been correctly configured with the required security header configurations. The study found that 70% to 100% of the web-based applications in Africa have not been correctly configured with the required security headers. This has accelerated cyber-attacks (such as cross-site scripting and SQL injection attacks) on information systems. For enhancing security in web-based systems, the study recommends the adoption and correct configuration of the security headers in web-based systems. Web-based protocols should be enhanced to automatically check the minimum enforcement of these security headers.
The authors declare no conflicts of interest regarding the publication of this paper.
Mlyatu, M.M. and Sanga, C. (2023) Secure Web Application Technologies Implementation through Hardening Security Headers Using Automated Threat Modelling Techniques. Journal of Information Security, 14, 1-15. https://doi.org/10.4236/jis.2023.141001