Web Security

Cybersecurity / 12 Sep 2026 / 7 min read

Control Referrer Data with Referrer-Policy

A browser can attach source-page information to an outbound request through the HTTP Referer header. That context can help with analytics, navigation flows, and abuse detection, but it can also expose more URL data than a destination needs. An explicit Referrer-Policy gives a site control over this boundary. The main security objective is simple: send the minimum source context needed for legitimate behavior, especially when a request crosses to another origin.

Cybersecurity Web Security

Cybersecurity / 11 Sep 2026 / 9 min read

Validate WebSocket Origins Before Accepting Browser Connections

A WebSocket connection can stay open for minutes or hours and carry commands in both directions. If a browser automatically attaches an authenticated session to the opening handshake, a hostile web page may be able to start that connection in the user’s browser unless the server checks which site initiated it. That creates a cross-site trust problem. The user can be signed in to app.example, visit another site in a separate tab, and still have the browser make requests that involve credentials associated with app.example. A WebSocket server that accepts the handshake based only on those credentials can give an untrusted page access to an authenticated channel.

Cybersecurity Web Security

Cybersecurity / 11 Sep 2026 / 7 min read

Validate Origin Before Trusting Browser Requests

A web endpoint can receive a valid session cookie and still receive a request that the user did not intend to send. Browsers attach cookies according to cookie rules, not according to the intent of the page that caused a request. For sensitive state changes, that distinction matters. One useful defense is to check the request’s browser origin before accepting the action. An origin identifies the scheme, host, and port of the context that initiated a request. Comparing it with a small set of expected origins can reject requests arriving from browser contexts your application does not trust.

Cybersecurity Web Security

Cybersecurity / 11 Sep 2026 / 9 min read

Validate Host Authority Before Trusting Request Metadata

HTTP applications often need to know which host a client intended to reach. Frameworks expose that value through fields such as Host, request.host, or a parsed request authority. It can look like infrastructure metadata, but at an application boundary it is commonly influenced by the client. That distinction matters when an application uses the value for security-sensitive work. A hostile authority can affect absolute links, redirects, cache entries, tenant selection, origin checks, or routing decisions if the application accepts it without a trust policy.

Cybersecurity Web Security

Cybersecurity / 11 Sep 2026 / 10 min read

Reject Ambiguous HTTP Request Framing

A reverse proxy and an application server can both accept the same HTTP connection and still disagree about where one request ends and the next begins. That disagreement is more than a parsing bug. On a reused connection, bytes that one component treats as part of a request can be interpreted by another component as the start of a second request. This class of problem is called HTTP request smuggling, or more generally HTTP desynchronization. The practical defensive goal isn’t to recognize every historical attack variation. It is to make request boundaries unambiguous at every hop, reject malformed framing instead of guessing, and test the exact proxy-to-backend path that production traffic uses.

Cybersecurity Web Security

Cybersecurity / 11 Sep 2026 / 9 min read

Keep Bearer Tokens Out of URLs

A bearer token grants access to whoever presents it successfully. That makes its storage and transport path part of the authentication design. If an application places such a token in a URL, the credential can travel into systems that were built to record or process URLs rather than protect secrets. The immediate request may still use HTTPS. The problem is what happens around that request: server access logs, reverse proxies, monitoring tools, browser history, support captures, and analytics pipelines can all handle URL data. A token copied into those places gains more exposure paths and can remain there long after the request finishes.

Cybersecurity Authentication

Cybersecurity / 11 Sep 2026 / 8 min read

Enforce HTTPS with HTTP Strict Transport Security

TLS protects an HTTP connection after the browser has chosen HTTPS and completed certificate validation. A separate problem exists before that protected connection begins: a user can type a bare hostname, follow an old HTTP link, or reach a page that redirects from HTTP to HTTPS. HTTP Strict Transport Security, usually called HSTS, lets a site tell supporting browsers to treat future connections to that host as HTTPS-only. The browser stores the policy for a defined period. While the policy is active, an HTTP navigation is upgraded locally before an insecure HTTP request is sent.

Cybersecurity Web Security

Cybersecurity / 11 Sep 2026 / 10 min read

Do Not Build Security Links from Untrusted Host Headers

Applications often need to send absolute URLs. A password reset email, account verification message, or administrative invitation needs a link such as https://accounts.example/reset?..., not just /reset?.... A tempting implementation takes the hostname from the current HTTP request and attaches the security-sensitive path. That works in ordinary testing, but it confuses two different facts: where the request says it was addressed and which public origin the application trusts for security links. If an untrusted request can influence the first value, it may influence a link containing a secret token.

Cybersecurity Web Security

Cybersecurity / 11 Sep 2026 / 8 min read

Block Clickjacking with an Explicit Framing Policy

A sensitive web page can have sound authentication and authorization yet still be exposed through another site’s interface. If an attacker can place that page inside a transparent or disguised frame, a signed-in user may believe they are clicking one control while their click reaches a different control in the framed application. That attack class is clickjacking, also called UI redressing. The browser is doing what both pages request; the security failure is that the sensitive application allowed an untrusted page to become part of its user interface.

Cybersecurity Web Security

Cybersecurity / 10 Sep 2026 / 9 min read

Pin Third-Party Browser Assets with Subresource Integrity

Loading JavaScript directly from another organisation’s server creates a security dependency that is easy to overlook. Your page may contain only a short <script> tag, but the downloaded file executes with the privileges that your site gives that script. If the file at that URL changes unexpectedly, your users can receive code you never reviewed or deployed. Subresource Integrity (SRI) gives the browser an expected cryptographic hash for a fetched resource. The browser hashes the bytes it receives and loads the resource only when the result matches the declared value. That turns “load whatever this URL serves” into “load the specific content I approved from this URL.”

Cybersecurity Software Supply Chain

Cybersecurity / 10 Sep 2026 / 10 min read

Keep User-Controlled Redirects on Trusted Destinations

Login flows often need to remember where a user was going. A request arrives for /billing, the application sends the user to sign in, then redirects them back after authentication. The feature is useful, but it becomes an open redirect when an untrusted value can make the application send the browser to an arbitrary destination. That matters because the redirect begins on a domain the user already trusts. A crafted link can legitimately reach your application and then immediately send the browser somewhere you never intended. Redirect parameters can also cross security boundaries in authentication and authorization flows when code assumes that “after login” is automatically a trusted place.

Cybersecurity Web Security

Cybersecurity / 10 Sep 2026 / 8 min read

Keep Untrusted Redirects on Your Own Origin

A login page often needs to remember where a user was going. After authentication, the application might read a next or return_to parameter and send the browser there. The feature looks harmless because the redirect happens only after the application has finished its real work. The problem appears when that parameter can name any destination. An attacker can then distribute a link on your trusted domain that immediately sends visitors somewhere the attacker chose. This is an open redirect: untrusted input controls the destination of an HTTP redirect without a sufficiently strict destination policy.

Cybersecurity Secure Coding

Cybersecurity / 10 Sep 2026 / 8 min read

Keep Private Responses Out of Shared Caches

A cache can make a web application faster by reusing a response instead of asking the application to generate it again. That becomes a security problem when the reused response contains data for one particular user. If a shared cache stores a personalized account page under a key that does not distinguish users, a later requester may receive the first user’s response. Authentication at the application can be perfectly correct and the data can still cross an authorization boundary because the second request never reaches that application logic.

Cybersecurity Web Security

Cybersecurity / 10 Sep 2026 / 10 min read

Do Not Bind Web Sessions to IP Addresses

A stolen session cookie can let someone use an account without knowing the user’s password. That makes a simple defense sound attractive: remember the IP address used at login and reject the session whenever the address changes. The problem is that an IP address is usually a property of the user’s current network path, not a stable property of the user or device. Legitimate addresses change, while different people can share one address. Strict IP binding can therefore lock out real users without reliably stopping an attacker.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 12 min read

Bind OAuth Callbacks to the Login That Started Them

An OAuth callback can look valid even when it belongs to the wrong browser interaction. The authorization server may have issued a real code, the redirect URI may be correct, and the code exchange may succeed. Yet if the client cannot tell whether this browser actually started that authorization flow, it can attach the wrong external identity or authorization to the current session. This is a form of cross-site request forgery at the OAuth callback. In a login flow, one possible consequence is login CSRF: a victim can end up signed into the client as an account associated with someone else. The details vary by application, but the defensive question stays the same: does this callback belong to a login transaction that this user agent started?

Cybersecurity OAuth

Cybersecurity / 09 Sep 2026 / 8 min read

Keep Session Cookies Bound to the Host That Needs Them

A web application can protect its session identifier with HTTPS and HttpOnly and still give more hosts influence over that session than intended. The problem is often the cookie’s Domain attribute. Suppose the authenticated application is app.example.com, while docs.example.com, status.example.com, and temporary preview hosts live under the same parent domain. If the session cookie is deliberately scoped to example.com, it can be sent to subdomains that do not need it. More broadly scoped cookies also make sibling subdomains part of the cookie’s integrity boundary: a sibling that can set cookies for the parent domain may be able to create a cookie with the same name and interfere with how the application interprets session state.

Cybersecurity Session Security

Cybersecurity / 09 Sep 2026 / 10 min read

Build Security-Sensitive URLs from Trusted Origins

A password-reset endpoint often needs to send an absolute URL such as https://accounts.example/reset?.... A tempting implementation is to take the hostname from the incoming HTTP request and prepend it to the reset path. That shortcut creates a trust problem. The request’s authority information, commonly exposed to application code through Host, :authority, or proxy-derived host fields, describes where the client says the request is addressed. It is not proof that the value is an approved public origin for links containing sensitive tokens.

Cybersecurity Secure Coding

Cybersecurity / 08 Sep 2026 / 12 min read

Use Content Security Policy as XSS Defense in Depth

A web application can carefully encode output and still acquire an injection bug later through a new template, a third-party component, or unsafe client-side code. If attacker-controlled text reaches a place where the browser interprets it as JavaScript, the result can be cross-site scripting (XSS): code runs in the security context of the application and can act with whatever authority the page already has. The primary fix is to stop untrusted data from becoming executable code. Content Security Policy (CSP) adds a second boundary. The server sends a policy that tells the browser which scripts are allowed to execute. A well-designed policy can therefore reduce the impact of some XSS flaws even when the application accidentally places attacker-controlled markup into a page.

Cybersecurity Web Security

Cybersecurity / 07 Sep 2026 / 9 min read

Match OAuth Redirect URIs Exactly

An OAuth authorization server eventually has to answer a deceptively simple question: where may it send the browser after authorization? If that destination is validated too loosely, an authorization response intended for one client can be sent somewhere the client does not control. In an authorization-code flow, that can expose the authorization code to another endpoint. Other protections may still limit what can be done with a leaked code, but redirect validation should not create the leak in the first place.

Cybersecurity OAuth

Cybersecurity / 06 Sep 2026 / 9 min read

Treat Request Hosts as Untrusted Input

Web applications often need to know their own public hostname. A framework may expose it as request.host, a reverse proxy may forward it in a header, and application code may use it to build an absolute URL. That is convenient, but it can quietly turn request-controlled data into a security decision. If an application accepts an arbitrary request host and later places that value into a password-reset link, redirect, cache entry, or routing decision, an attacker may be able to make trusted application output point at an unintended host. The exact consequence depends on where the value is used, but the underlying mistake is the same: treating a routing identifier supplied with a request as if it were trusted configuration.

Cybersecurity Web Security

Cybersecurity / 06 Sep 2026 / 10 min read

Treat CORS as a Browser Read Permission

A browser application often needs to call an API on another origin. The first time this fails, Cross-Origin Resource Sharing (CORS) can look like a networking obstacle: the request reached the server, the server returned data, yet JavaScript cannot read the response. That view leads to a dangerous fix—making the CORS policy broad until the error disappears. CORS is better understood as a browser-enforced read permission. Your server uses HTTP response headers to tell a browser which other origins may expose a response to their JavaScript. If a sensitive API grants that permission too broadly, code running on an unintended website may be able to read data in a user’s browser context. If the policy is too narrow, legitimate frontends stop working.

Cybersecurity Web Security

Cybersecurity / 06 Sep 2026 / 9 min read

Serve User Uploads as Untrusted Content

Accepting a file is only half of an upload feature. The other half is deciding what happens when someone retrieves that file. A file that was harmless while sitting in object storage can become a security problem when a browser receives it from your application’s origin. If the response is interpreted as active content, the uploaded bytes may gain privileges that the uploader should never have had. Even files that are meant only for download can expose other users when authorization, response metadata, or storage boundaries are wrong.

Cybersecurity File Upload Security

Cybersecurity / 06 Sep 2026 / 10 min read

Keep Sensitive Data Out of URLs

A URL is convenient because it is easy to copy, bookmark, route, log, and inspect. Those same properties make it a poor place for passwords, long-lived access tokens, recovery secrets, or other values that should remain confidential. The problem is not that HTTPS exposes the URL to everyone on the network. HTTPS protects the request in transit between endpoints under its security assumptions. The problem is what happens before and after transport: URLs routinely pass through browser history, application and proxy logging, monitoring systems, support messages, screenshots, and copied links. A secret placed in a URL can therefore reach systems and people that never needed the secret.

Cybersecurity Data Exposure

Cybersecurity / 05 Sep 2026 / 11 min read

Do Not Trust the Request Host for Security-Sensitive URLs

Applications sometimes need to create an absolute URL. A password-reset email, email-verification message, or security notification may need a link such as https://accounts.example.com/reset/... rather than a relative path. A tempting implementation takes the host name from the current HTTP request and combines it with the path. That is convenient, but it can quietly move a security decision into attacker-controlled input. If the deployment accepts an unexpected host value, the application may generate a valid security token inside a link pointing at the wrong site.

Cybersecurity Secure Coding