{"dataset":{"id":"00000000-0000-0000-0000-000000000046","slug":"web-security-best-practices","name":"Web security best practices","description":"Source-linked guidance on core web security controls: HTTPS enforcement with HSTS, Content Security Policy, cookie attributes, XSS prevention, and CORS. Scoped to browser-level web security as documented by MDN; not a general application-security corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Cross-Origin Resource Sharing (CORS)","sourceUrl":"https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS","text":"Cross-Origin Resource Sharing (CORS) is an HTTP-header mechanism that lets a server indicate any origins other than its own from which a browser should permit loading resources, relaxing the same-origin policy for APIs such as fetch() and XMLHttpRequest. For requests that can cause side effects — methods other than GET, or POST with certain MIME types — the specification mandates that browsers preflight the request: they send an HTTP OPTIONS request soliciting supported methods from the server and, upon approval, send the actual request. Servers use response headers to declare which origins are allowed and whether user credentials such as cookies and HTTP authentication should accompany requests; when making credentialed requests to a different domain, third-party cookie policies still apply. CORS also governs resources such as web fonts, WebGL textures, and images drawn into a canvas with drawImage(). When a CORS check fails the browser raises an error, but for security reasons the specifics of the failure are not available to JavaScript. Scope: Web security. Reviewed October 4, 2026.","id":"web-security-best-practices:Cross-Origin Resource Sharing (CORS)","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Preventing cross-site scripting","sourceUrl":"https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS","text":"Cross-site scripting (XSS) occurs when a website accepts input crafted by an attacker and includes it in its pages without sanitizing it to remove or neutralize executable JavaScript. The browser's same-origin policy is meant to keep different sites' code isolated, but XSS subverts it by tricking the target site into executing malicious code within its own context, as though it were same-origin — letting the attacker modify page content, read local storage, or make HTTP requests with the user's credentials, enabling impersonation and access to sensitive operations such as financial transactions. A canonical mistake is assigning unsanitized input, such as a name taken from a URL parameter, to an element's innerHTML property, which interprets its value as HTML; an attacker can supply markup such as an img element with an onerror handler to run arbitrary code. Defense means treating every piece of user-supplied data as text rather than code: validate input and encode output so injected markup can never execute in the page's context. Scope: Web security. Reviewed October 4, 2026.","id":"web-security-best-practices:Preventing cross-site scripting","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Cookie attributes that limit exposure","sourceUrl":"https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/Cookies","text":"Cookie hardening happens through Set-Cookie attributes and name prefixes. Prefix names with __Host- for cookies needed only on a specific domain (no subdomains) where Path is set to /, and __Secure- for all other cookies; both prefixes prevent cookies from being overwritten by insecure sources. Always set Secure so the cookie is transmitted only over HTTPS, and set HttpOnly on every cookie that does not require access from JavaScript — session identifiers above all. Cookies should expire as soon as they are no longer needed: Expires sets an absolute expiration date, Max-Age a relative one, and Max-Age is less error-prone and takes precedence when both are set; if neither is set, the cookie is kept until the user closes the browser and is then discarded. Restrict Domain and Path to the tightest scope the application needs. Setting SameSite to Strict or Lax restricts cookie transmission in requests that originate from a different site, defending against cross-site request forgery (CSRF), clickjacking, and some cross-site leak attacks. Scope: Web security. Reviewed October 4, 2026.","id":"web-security-best-practices:Cookie attributes that limit exposure","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Content Security Policy for XSS, clickjacking, and HTTPS","sourceUrl":"https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP","text":"Content Security Policy (CSP) lets a site instruct the browser to restrict what its code may do, and its primary control is restricting the resources — especially JavaScript — a page can load, defending against cross-site scripting (XSS) attacks in which an attacker injects malicious code. CSP also protects against clickjacking: the frame-ancestors directive controls which documents, if any, may embed the page in a nested browsing context such as an iframe. The upgrade-insecure-requests directive makes the browser upgrade HTTP URLs to HTTPS for resource loads, same-origin navigation requests, and form submissions, though cross-origin top-level navigations are not upgraded. CSP can additionally enforce trusted types against client-side XSS. These protections are independent, so a site can deploy only the directives it needs. Deliver the policy in the Content-Security-Policy response header on all responses; a meta element with http-equiv is a useful option for a static client-side-rendered app without server infrastructure. A policy is a semicolon-separated list of directives: default-src 'self' sets a same-origin fallback for fetch directives not explicitly listed, and img-src governs image sources. Scope: Web security. Reviewed October 4, 2026.","id":"web-security-best-practices:Content Security Policy for XSS, clickjacking, and HTTPS","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"HTTPS enforcement with Strict-Transport-Security","sourceUrl":"https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security","text":"The Strict-Transport-Security response header (HSTS) tells browsers that a host should only be accessed over HTTPS: future attempts to use HTTP are automatically upgraded, and the browser will not let the user bypass secure connection errors such as an invalid certificate. The max-age directive sets, in seconds, how long the browser remembers the policy, and each response that carries the header refreshes that expiration; includeSubDomains extends the policy to all subdomains. To qualify for preloading, max-age must be at least 31536000 (one year) and includeSubDomains must be present. A host is identified by domain name only — an IP address cannot be an HSTS host — and the policy applies to all ports: the browser rewrites port 80 to 443 while leaving other explicit ports unchanged. The header must be sent over HTTPS; browsers ignore it over HTTP so a manipulator in the middle cannot plant or prematurely expire a policy. Scope: Web security. Reviewed October 4, 2026.","id":"web-security-best-practices:HTTPS enforcement with Strict-Transport-Security","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}