We analyzed over 25,000 primary and secondary school websites to assess whether they had implemented seven common browser-side security controls. The results revealed a stark divide: only 52 schools (0.2%) implemented all seven controls, while more than a quarter (27.5%) had none.

These controls are baseline defences against common cyberattacks that trick web browsers into leaking data and running malicious code. Their absence leaves students, their families, and faculty exposed to easily preventable attacks when visiting school websites.

Key findings:

  • Just 0.2% of schools had all of the key website security controls in place
  • More than a quarter of schools had none of the key website security controls
  • Primary school websites outperformed secondary school websites across every security control
  • 36.7% of schools lacked HSTS
  • Less than a third of schools had a Content Security Policy (CSP)
  • More than 60% of school websites lacked X-Frame-Options
  • More than 40% of school websites lacked the X-Content-Type-Options header
  • 57.7% of schools lacked a Referrer Policy
  • Just 16% of school websites used a Permissions Policy
  • Fewer than a third of schools provided a security.txt file

The seven security controls we analyzed were:

  • HSTS present: HTTP Strict Transport Security (HSTS) ensures browsers only connect using secure HTTPS connections. This helps to protect users’ privacy and prevent hacks, e.g. man-in-the-middle attacks and cookie hijacking.
  • CSP present: Restricts which scripts and other resources a browser can load.
  • X-Frame-Options present: Helps prevent the site from being embedded in hidden or transparent iframes on unauthorized sites, stopping users from being tricked into clicking on malicious links or buttons.
  • X-Content-Type-Options present: Prevents browsers from guessing (“sniffing”) a file format or type if it’s unclear/missing. This protects against cross-site scripting (XSS) and content confusion attacks.
  • Referrer-Policy present: Controls what referrer information is shared with other sites, reducing the risk of sensitive data, such as user IDs or secret paths, from being exposed when users click on external links.
  • Permissions-Policy present: Controls which browser features and APIs (e.g. geolocation or cameras) the site and embedded third-party content can use. This restricts intrusive third-party scripts and reduces the risk of XSS and injection attacks, while also protecting users’ privacy by only allowing what’s necessary for the site’s function.
  • security.txt present: Provides security researchers with information for reporting vulnerabilities.

Primary schools vs. secondary schools

Primary schools performed better than secondary schools overall. An average of 2.82 website security controls were implemented across all of the websites we analyzed, with primary schools implementing an average of 2.9, compared to 2.6 among secondary schools.

Only 0.2% of primary and 0.2% of secondary schools implemented all seven security controls. Just under 27% of primary schools had zero controls, compared to 31% of secondary schools.

A greater percentage of primary schools implemented five of the security controls (26.8% versus 20.6%). Secondary schools were more likely to implement just one or two security controls.

These seven controls are the baseline defences against the most common ways a browser can be tricked into leaking data or running malicious code. Their absence leaves schools needlessly exposed to attacks that a few lines of server configuration could prevent.

The most concerning omission: no content security policy

CSP is often considered the strongest single browser-side defence. However, just under a third of schools (8,166) have adopted it. Of these, 89.1% (7,277 schools) had what we’d consider to be a strong CSP implementation. A CSP tells the browser what content is allowed to load and execute on a web page. If strictly applied, it can limit potentially malicious scripts, styles, images, frames, fonts, and media from being used. CSP’s ability to stop third-party scripts from running means it protects against XSS, which many experts consider the most dangerous web vulnerability.

Compared with secondary schools, a slightly greater percentage of primary schools had a strong CSP implementation (29.3% compared to 25.6%).

However, CSP isn’t always strictly applied. The sites with moderate or weak CSP included the unsafe-inline and unsafe-eval directives in their headers, which largely remove any protections against XSS.

  • unsafe-inline allows untrusted inline scripts to run
  • unsafe-eval allows JavaScript functions that execute strings as code to run.

The presence of these directives means that an attacker who finds an XSS bug can get their malicious code to execute. For this reason, authorities such as OWASP recommend avoiding them. In practice, however, developers may add them because their code relies on inline scripts or eval-based patterns. It’s easier to allow these than to rework the code to be CSP-compliant.

Overall, the CSP figures suggest an adoption gap rather than an implementation-quality gap. Schools that did have a CSP did it well.

Other missing protections

Schools adopted fewer security controls that require manual configuration, despite several of them being easy to implement.

16% of school websites had a permissions policy

4,086 out of 25,454 of all school websites had a permissions policy. This included 16.2% of primary schools and 15.1% of secondary schools.

A Permissions Policy allows developers to specify what browser features/APIs a site is allowed to use. So, for example, it could be used to restrict a site from using sensitive devices like a camera or microphone.

29% of school websites had a security.txt file

7,439 of all school websites had a security.txt file. This included 30.5% of primary schools and 23.8% of secondary schools.

A security.txt file allows third parties to safely report security flaws in the website. With no reporting mechanism, site vulnerabilities may remain unaddressed.

39% of school websites had an X-Frame-Options response header

10,030 of all school websites had an HTTP X-Frame-Options response header present. This included 40.3% of primary schools and 35.7% of secondary schools.

The X-Frame-Options HTTP response header helps prevent clickjacking attacks by controlling whether a webpage can be embedded inside a frame or iframe on another website.

42% of school websites had a Referrer Policy

10,758 of all school websites had a Referrer Policy present. This included 44% of primary schools and 35.1% of secondary schools.

A Referrer Policy matters because it helps protect user privacy and sensitive information by controlling what browsing details are shared with other websites. Although this is more of a privacy issue than a critical security flaw, it is increasingly regarded as standard practice.

59% of school websites had an X-Content-Type-Options response header

15,084 of all school websites had an X-Content-Type-Options response header present: 61.3% of primary schools and 50.8% of secondary schools.

The header is important because it prevents browsers from MIME-sniffing files and interpreting them as a different content type, reducing the risk of malicious scripts being executed.

63% of school websites use HSTS

16,116 of all school websites used HTTP Strict Transport Security (HSTS). This included 65.4% of primary schools and 54.6% of secondary schools.

HSTS tells browsers to use HTTPS rather than HTTP for future connections, helping prevent attackers from exploiting an initial unencrypted HTTP connection to redirect users to a malicious site.

Most schools use modern encryption

Encryption standards were generally stronger than the browser-side security controls assessed in this study. TLS support was measured separately from the seven browser-side security controls and was not included in the seven-control score. 85.1% of primary schools and 78.5% of secondary schools negotiated TLS 1.3, while 93.5% of primary schools and 95.6% of secondary schools supported TLS 1.2.

TLS 1.3 is currently the most secure and efficient version of the protocol and is recommended by modern security standards. That said, 1.2 isn’t deprecated yet, so it is safe enough–for now.

Most sites used modern AES-GCM cipher suites and secure RSA or ECDSA certificates with industry-standard key sizes.

Overall maturity assessment

The results suggest that UK school websites demonstrate a mixed level of security maturity. Most schools have implemented HTTPS using modern encryption standards, with 83.8% of schools supporting TLS 1.3 and the overwhelming majority (93.9%) supporting TLS 1.2. Secure certificate configurations and modern cipher suites were also common, indicating that basic transport-layer security is generally well established.

However, adoption of browser-side security controls was substantially weaker. Fewer than a third of schools used a Content Security Policy. Similarly, just under a third maintained a security.txt file. Most notably, only 52 out of 25,454 schools (0.2%) implemented all seven assessed security controls, while 7,001 (27.5%) implemented none of them.

From these findings, we can infer that many schools rely on secure hosting and default HTTPS configurations provided by website platforms, hosting providers, or content delivery networks, but have not implemented additional measures that help defend against common web attacks such as cross-site scripting, clickjacking, information leakage, and insecure browser behaviour.

Overall, the sector appears to have achieved a reasonable baseline level of encryption maturity but lags behind government-recommended best practices for web application hardening and security governance.

Methodology

We analysed 25,454 UK primary and secondary/private school websites using URLs available at schoolswebdirectory.co.uk. This comprised 20,450 primary school websites and 5,004 secondary/private school websites.

For each website, we recorded the negotiated TLS version, support for TLS 1.2 and TLS 1.3, certificate status, and the presence of common HTTP security controls including HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, security.txt, and Permissions-Policy. We only checked the homepage of each site, but it’s possible that security headers vary across other school applications and subdomains.

The seven assessed controls were selected because they are widely recognised browser-side security measures that can be evaluated remotely without access to a website’s internal systems. Together, they help mitigate a range of common web-based attacks, including cross-site scripting (XSS), clickjacking, content-type confusion, information leakage, and insecure connections. They also indicate whether an organisation has implemented basic security governance measures, such as a mechanism for vulnerability reporting. While the presence of these controls does not guarantee a website is secure, their absence may suggest that fundamental web security practices have not been fully implemented.

These controls were chosen because they are externally observable and broadly applicable across website technologies. The study does not assess server-side security measures, patching practices, authentication controls, or vulnerability management processes, meaning the results should be interpreted as a broad indication of web security posture rather than a comprehensive assessment of overall cybersecurity.

Content Security Policies were scored out of 10 and classified as strong (8 to 10), moderate (5 to 7), or weak (0 to 4). We used a scoring methodology based on recognized CSP best practices and common misconfigurations. Each website started with a score that was capped at 10. Sites lose points for bad practices and gain them for good ones.