OneWebDesk

Web Security

Security headers, CSP, CORS and exposure checks.

The tools in the Web Security category inspect the security settings your site sends to browsers, helping you block common attacks like XSS, clickjacking, session hijacking, and data leakage. In one place you can check and decode security headers (HSTS, X-Frame-Options, X-Content-Type-Options), Content Security Policy (CSP), CORS configuration, cookie security flags (Secure, HttpOnly, SameSite), Permissions Policy and Referrer Policy, security.txt, and Subresource Integrity (SRI). They are built for web developers, frontend engineers, site operators, and anyone preparing for a security audit who needs to spot missing headers or misconfigured policies quickly, before and after a deploy.

A typical workflow starts by reviewing the full set of response headers to see which security headers are missing, then decoding complex policies like CSP and CORS directive by directive to tighten anything overly permissive (for example unsafe-inline or a wildcard *). From there you review your cookies' SameSite, Secure, and HttpOnly combination, confirm that external scripts carry SRI hashes, and make sure security.txt exposes a contact channel for vulnerability reports. Because every check simply interprets the headers and policy strings a browser actually sees, the best approach is iterative: change a setting, re-run the check, and confirm the result improved.

Frequently asked questions

Which security headers should I apply first?
The highest-priority headers are HSTS (forces HTTPS), X-Frame-Options or CSP's frame-ancestors (blocks clickjacking), and X-Content-Type-Options: nosniff (blocks MIME sniffing). These three have minimal side effects and are safe to apply to almost any site. After that, introduce a Content Security Policy gradually to control XSS and resource loading.
What is the difference between CSP and CORS?
CSP (Content Security Policy) restricts which origins your page is allowed to load and run scripts, styles, images, and other resources from, reducing XSS. CORS, on the other hand, decides whether JavaScript running on another origin (domain) may access your API or resources. Both deal with origins, but CSP controls 'what I load' while CORS controls 'who is allowed to call me.'
What value should I use for a cookie's SameSite attribute?
For most session cookies, SameSite=Lax is a safe default and blocks a large share of CSRF attacks. If a cookie must be sent in cross-site contexts such as iframes, use SameSite=None, but you must also add the Secure flag so it is only sent over HTTPS. For session and authentication cookies, also add HttpOnly to block JavaScript access.
Are these checks safe? Are the URLs or headers I enter sent anywhere?
For client-only tools, the headers and policy strings you enter are interpreted entirely in your browser and never sent to an external server. Some tools that fetch a site's live response headers do go through a server, but they do not store results and only handle publicly accessible response headers. Each tool page states its handling method in its FAQ.