Public protection and application hardening
Security is more than a score. This cluster starts with controls that can be observed on the public website, then explains the deeper application checks a URL scan cannot establish. Use each guide as a review aid, not as a security certification.
Scan a website first→20 editorial guides
Practical guides for reviewing public security headers and the application safeguards that still require repository or runtime access.
A Content Security Policy limits which resources a browser may load and execute. The useful version is tailored to the real application, monitored before enforcement and kept restrictive as the product changes.
Read guide →HSTS tells browsers to keep using HTTPS after a secure visit. Its value depends on correct HTTPS coverage, a deliberate lifetime and careful treatment of subdomains.
Read guide →Permissions Policy limits access to browser features such as camera, microphone and geolocation. A narrow policy reduces accidental capability exposure without changing normal page content.
Read guide →Referrer Policy controls how much URL information accompanies navigation and resource requests. The right setting preserves useful attribution without leaking sensitive paths or parameters.
Read guide →The nosniff directive tells browsers to respect declared content types. It is a small header that becomes effective only when assets are also served with accurate MIME types.
Read guide →Frame controls decide which sites may embed a page. A clear policy protects sensitive actions while allowing intentional embeds to continue working.
Read guide →Cookie flags shape how browsers send session and preference data. Secure, HttpOnly and SameSite settings should match the cookie’s actual role and cross-site requirements.
Read guide →Cross-site request forgery defenses ensure that a browser request represents the user’s intended action. Cookie settings help, but sensitive actions still need explicit server-side protection.
Read guide →CORS is a browser access policy, not an authentication mechanism. A safe configuration returns only intended origins, methods, headers and credential behavior.
Read guide →Rate limits protect availability and cost by constraining repeated actions. Effective limits are keyed to the abuse model and return predictable recovery information.
Read guide →Secrets should be scoped, rotated and delivered through the deployment environment rather than source code or client bundles. Public scanning cannot prove that this boundary is intact.
Read guide →Dependency review combines provenance, known vulnerabilities, update discipline and runtime reachability. A lockfile is evidence of repeatability, not evidence that every package is safe.
Read guide →Authentication security includes enrollment, login, recovery, session renewal and logout. Each transition needs abuse resistance and predictable failure behavior.
Read guide →Authorization determines whether an authenticated identity may perform a specific action on a specific object. The server must enforce it regardless of what the interface hides.
Read guide →Validation ensures incoming data matches the shape, range and meaning the application accepts. It belongs at each trusted boundary even when the client already validates forms.
Read guide →Output encoding prevents untrusted data from becoming executable markup or script. The correct defense depends on whether data enters HTML, attributes, URLs, JavaScript or CSS.
Read guide →Uploads combine untrusted content, storage cost and public delivery risk. Controls should validate the real file, isolate processing and prevent user content from becoming executable.
Read guide →Public errors should explain recovery without revealing stack traces, secrets, queries or internal topology. Detailed diagnostic context belongs in protected logs.
Read guide →Security logs should answer what happened, when, to which resource and under which identity without becoming a new store of secrets or excessive personal data.
Read guide →External scripts execute with the page’s authority. Every tag should have a business owner, a constrained loading path and a removal plan when the dependency is no longer justified.
Read guide →