Practical Security Guides For Your Team

Your server is configured to trust any website that contacts it, including malicious ones. This means if one of your logged-in users visits a harmful website, that site can silently pull data from your application — such as account details, API keys, or personal information — without the user knowing. Think of it like a bank teller who hands over account information to anyone who calls, as long as they say the right words.

Your website has a security header called a Content Security Policy (CSP) — think of it like a bouncer that controls which scripts are allowed to run on your pages. Right now, two settings in that policy ('unsafe-inline' and 'unsafe-eval') are telling the bouncer to let almost anyone in, which largely defeats the purpose of having one. This is a defence layer that isn't doing its job properly, not an active attack.

Your application is configured to allow any website in the world to read responses from your server. Think of it like leaving your office filing cabinet unlocked — anyone who walks past can look inside. For pages that are genuinely public (like a marketing site), this is fine. For pages that return user data, account info, or internal details, it's a gap worth closing.

Your website already uses a secure connection (HTTPS), which is great. But there's a setting that tells browsers how long to remember to always use that secure connection — and yours is set too low. Think of it like a reminder that expires too quickly: if a user's browser forgets before their next visit, there's a brief window where they could be exposed to a connection that isn't fully protected.

Your website is missing a security setting that tells browsers whether your pages are allowed to be embedded inside other websites. Without it, a malicious site could invisibly overlay your pages to trick your visitors into clicking buttons or links they didn't intend to — a technique called clickjacking. This is a missing protection layer, not an active attack in progress.

Your website is missing a small but important instruction it should send to browsers — one that tells them to always use a secure, encrypted connection. Without it, browsers may occasionally connect over an unencrypted channel, and there is no browser-level safeguard to prevent that from happening. Think of it like a lock on your front door: your HTTPS certificate is the lock, but this header is the sign that tells visitors to always use the locked entrance.