Website Security: Static Sites & Attacks

G5 Cyber Security

1 week ago

TL;DR

Yes, attackers can still mess with a website even if it doesn’t have a server-side back end (like PHP or Node.js). They can modify files directly on your hosting provider if you don’t protect them properly. This guide explains how to prevent that.

Understanding the Risks

Static websites are built from HTML, CSS, and JavaScript files served directly by a web server (like Nginx or Apache) or a Content Delivery Network (CDN). Because there’s no back-end code processing requests, they *seem* more secure. However, attackers can still exploit vulnerabilities:

File Modification: If an attacker gains access to your hosting account or the server itself, they can directly change your website files.
Cross-Site Scripting (XSS): While less common in purely static sites, XSS is possible if you include user-supplied content without proper sanitisation.
Defacement: Changing the main page or other key files to display a malicious message.
Malware Injection: Injecting malicious JavaScript code into your site.

How to Protect Your Static Website

Secure Your Hosting Account:
- Strong Password: Use a long, complex password for your hosting account and any associated FTP/SFTP accounts.
- Two-Factor Authentication (2FA): Enable 2FA wherever possible. This adds an extra layer of security beyond just a password.
- Limit User Access: Only grant access to the minimum number of people who need it, and give them the least privileges necessary.
Use SFTP Instead of FTP:
FTP transmits data in plain text, making it vulnerable to eavesdropping. SFTP encrypts your connection.
```
# Example using FileZilla - choose SFTP as the protocol
```

File Permissions:

Set appropriate file permissions on your server. Generally, files should be readable by the webserver user but not writable.

# Example using SSH (Linux/macOS) - change 'www-data' to your webserver user
chmod 644 *  # Files: read/write for owner, read only for others
chmod 755 directories # Directories: read/write/execute for owner, read/execute for others

Content Security Policy (CSP):
CSP helps prevent XSS attacks by controlling which sources your browser is allowed to load resources from.
```
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'unsafe-inline' https://trusted.cdn.com; style-src 'self' https://trusted.cdn.com; img-src 'self' data:";
```
Adjust the content attribute to match your website’s needs, allowing only trusted sources.
Subresource Integrity (SRI):
SRI ensures that files loaded from CDNs haven’t been tampered with. It uses cryptographic hashes to verify the integrity of downloaded resources.
```
<script src="https://trusted.cdn.com/jquery.min.js" integrity="sha384-…" crossorigin="anonymous">
```
Replace sha384-... with the actual SRI hash for the file.
Regular Backups:
Back up your website files regularly. This allows you to restore your site quickly if it’s compromised.
Automated Scanning (Optional):
Consider using a website security scanner to automatically check for vulnerabilities and malware. Many free and paid options are available.
HTTPS:
Always use HTTPS to encrypt traffic between your website and visitors. This protects against eavesdropping and man-in-the-middle attacks.

Important Considerations

Third-Party Scripts: Be careful when including third-party scripts (e.g., analytics, social media buttons). They can introduce vulnerabilities if they are compromised.
Form Handling: If your static site includes forms that submit data to a service, ensure the service handles security properly. Never process form data directly on the client side without validation and sanitisation.