Skip to content

Archive

Cybersecurity

535 articles
Cybersecurity 09 Sep 2026 10 min read

Validate DNS Results Before Connecting to Untrusted Hostnames

A server that accepts a hostname from a user can make a careful security decision and still connect somewhere it never intended. The common mistake is validating the hostname first, then assuming that the later network connection will reach the same kind of destination. Hostnames are names, not network locations. DNS turns a hostname into one or more IP addresses, and those answers can change. If your security rule says “public destinations only,” checking the text of the hostname is not enough. The connection must also be constrained to an address that satisfies that rule.

Cybersecurity 09 Sep 2026 8 min read

Treat Time as a Security Dependency

Security controls often depend on time without treating the clock itself as part of the control. A token may expire at a timestamp, a signed request may be accepted only for a short window, and investigators may reconstruct an incident by ordering events from several services. If those clocks are wrong, the security decision can be wrong too. A clock that jumps backward can extend a time-based window. Two servers with different wall clocks can disagree about whether the same credential is expired. Poorly synchronized log timestamps can make a correct sequence of events appear reversed.

Cybersecurity 09 Sep 2026 11 min read

Treat Spreadsheet Exports as Active Content

A CSV export can look harmless because the application is only writing text. The risk appears later, when a spreadsheet program opens that text and decides that a cell is a formula rather than ordinary data. If an attacker can control a field that appears in an export, a value intended to be a name, note, ticket title, or other text may be interpreted by the spreadsheet application as active spreadsheet content. The consequence depends on the spreadsheet software and its configuration, but it can include misleading calculated values, unexpected links or external interactions, and other behavior the exporting application never intended to authorize.

Cybersecurity 09 Sep 2026 10 min read

Treat Security Bypass Flags as Privileged Controls

A security control sometimes needs an emergency exception. A certificate check may need a temporary compatibility mode during a migration. A fraud rule may need a narrow exemption for a broken integration. An administrator may need a recovery path when the normal authentication service is unavailable. The dangerous mistake is to treat the switch that disables or weakens that control as ordinary configuration. If changing require_strong_check = true to false removes a protection, then permission to change that value carries security authority. A compromised deployment account, careless operator, stale test setting, or poorly protected configuration service can turn the exception into a persistent bypass.

Cybersecurity 09 Sep 2026 9 min read

Treat Client-Side Authorization State as Untrusted Input

Applications often send useful state to a client: a user role for rendering navigation, an owner identifier for displaying a record, or a flag that controls whether a button appears. The security problem begins when the server later accepts that client-supplied state as proof that an action is allowed. A client is outside the server’s trust boundary. A browser, mobile application, API consumer, or desktop client can send requests that differ from the interface the developer intended. If changing a client-controlled field can change an authorization result, a user may gain authority that the server never granted.

Cybersecurity 09 Sep 2026 11 min read

Treat Certificate Pinning as a High-Cost Trust Decision

TLS normally lets a client authenticate a server through a certificate chain anchored in a trusted certificate authority. A developer may look at that broad trust model and decide to add certificate pinning: require the server to present not only a normally valid certificate, but also certificate or public-key material that the application already expects. That extra restriction can reduce risk in a narrow threat model. It can also turn an ordinary certificate or key rotation into an outage if the application has no usable replacement pin. For many applications, especially ordinary websites, the operational risk is not justified.

Cybersecurity 09 Sep 2026 10 min read

Treat Account Email Changes as Security-Sensitive

Changing an account email address can look like an ordinary profile edit. In many systems, however, the email address is also used for sign-in, password recovery, security notifications, or proving control of the account. That makes the change a security-sensitive transition, not merely a text-field update. If an application lets a valid session replace the account email without additional checks, a stolen or unattended session may be enough to redirect future recovery messages to someone else. The legitimate user can then lose both a warning channel and a path back into the account.

Cybersecurity 09 Sep 2026 10 min read

Rate Limit by the Resource an Attacker Can Exhaust

A rate limit can look effective in testing and still fail against the abuse it was meant to control. The usual reason is not the counter or the algorithm. It is the key used to group requests. Suppose a password-recovery endpoint allows five requests per hour from each source address. That may slow one client, but it does not directly protect a user’s mailbox from receiving hundreds of recovery messages sent through many source addresses. The resource under pressure is the destination account or delivery channel, while the limit is counting something else.

Cybersecurity 09 Sep 2026 10 min read

Normalize Once Before Security Validation

A security check can inspect the right field and still make the wrong decision if another component interprets that field differently later. Consider an application that accepts a path-like identifier. One layer rejects values containing a forbidden segment. A later layer decodes or normalizes the value before using it. If those two layers do not agree on what the input means, the application may approve one representation and act on another.

Cybersecurity 09 Sep 2026 10 min read

Make Tenant Context Part of Every Authorization Decision

A multi-tenant application can have correct login logic and still expose one customer’s data to another. The failure often begins with an authorization check that asks only whether a user may access a resource, while forgetting to verify the tenant in whose context that access is being requested. A tenant is an isolated customer, organization, workspace, or similar security domain that shares an application with other tenants. Tenant isolation means actions intended for one tenant should not silently cross into another.

Cybersecurity 09 Sep 2026 10 min read

Make Sensitive Requests Replay-Resistant

A server can correctly prove that a request came from a trusted client and still process it more times than intended. If an authenticated request says “approve this payout” or “change this recovery address,” accepting the same valid request twice can create a security problem even though neither copy was forged. This is a replay problem. A replay happens when a previously valid message is presented again and the receiver cannot tell that its authority has already been used, or that the message is too old to trust.

Cybersecurity 09 Sep 2026 8 min read

Make Authorization Policy Conflicts Explicit

Authorization becomes difficult when more than one rule applies to the same request. One policy may grant a developer access to a project while another restricts access to confidential records. If the system has no explicit rule for combining those policies, a small implementation detail can decide whether access is granted. That is a security problem because developers, administrators, and reviewers may believe different policies take precedence. A later refactor can then change effective access without anyone intending to change the security model.

Cybersecurity 09 Sep 2026 11 min read

Limit Decompression Before Processing Untrusted Archives

An upload limit can look like a complete resource limit until the application accepts compressed input. A small archive may expand into far more data than its uploaded size suggests, contain an excessive number of entries, or require enough decompression work to tie up workers. If the service trusts the compressed size, an attacker may be able to exhaust disk, memory, CPU time, or processing capacity without sending a large request.

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 09 Sep 2026 10 min read

Keep Sensitive Data Out of Logs

Logs help developers diagnose failures and help security teams reconstruct important events. The same convenience can create a second problem: a log statement may copy passwords, session tokens, API keys, personal data, or confidential request contents into systems that were never meant to hold them. Once sensitive data reaches a log, it can spread to collectors, search indexes, dashboards, exports, support tools, and backups. Access controls on the original application no longer define every place where that data can be read. A credential that was protected in a secret store may become exposed through a much broader logging path.

Cybersecurity 09 Sep 2026 10 min read

Keep Security Logs Outside the System They Describe

Security logs often matter most after something has gone wrong. They help responders reconstruct which account acted, what changed, and when suspicious activity began. But there is a simple weakness in many logging designs: the system being investigated also controls the only copy of its own evidence. If an attacker gains enough privilege on that system, or if destructive failure affects its storage, local log files may be altered, deleted, or lost with the machine. The application may have recorded the right events and still leave responders with little useful history.

Cybersecurity 09 Sep 2026 10 min read

Keep Package Publishing Credentials Out of Untrusted Builds

A build job often needs to compile code, run tests, and create an artifact. It usually does not need permission to publish a new version that other people will install. That distinction matters because build systems process code and configuration that change frequently. A pull request, dependency update, test helper, build script, or compromised developer account can influence what runs during a build. If every such build also receives a long-lived package registry credential, code that only needed to be tested may inherit authority to release software.

Cybersecurity 09 Sep 2026 10 min read

Keep a Credential Inventory You Can Revoke

A service can have strong authentication and still accumulate a dangerous access problem: nobody can reliably answer which machine credentials are valid, who owns them, or which ones can be revoked. That uncertainty matters during routine maintenance and incidents. An old integration may disappear while its API key remains valid. A team may find a credential in a secret store but hesitate to disable it because the last known caller is unclear. If the credential is later exposed, its authority survives simply because nobody knows whether anything still depends on it.

Cybersecurity 09 Sep 2026 8 min read

Expire Sessions with Idle and Absolute Timeouts

A login session is convenient because a user does not need to authenticate on every request. The same property becomes a security problem when a session credential is copied: whoever possesses a usable credential may keep acting with the authority attached to it until the application stops accepting it. Expiration limits that window. But a single vague setting called “session timeout” is often not enough. Two different questions matter: how long may a session sit unused, and how long may it exist even if it stays active? These are the idle timeout and the absolute timeout.

Cybersecurity 09 Sep 2026 10 min read

Do Not Use Security Questions as Authenticators

An application can protect normal sign-in with a strong password or multi-factor authentication and then weaken the same account with one recovery question such as a pet name or birthplace. If answering that question is enough to reset a password or regain access, the question is effectively another authenticator. That matters because many personal facts are easier to discover, infer, reuse, or guess than a deliberately chosen authentication secret. The recovery path can therefore become easier to satisfy than the sign-in path it is meant to recover.

Cybersecurity 09 Sep 2026 9 min read

Design User Identifiers to Resist Visual Spoofing

Two account identifiers can be different to software while looking almost identical to a person. That gap matters anywhere people use a displayed identifier to decide whom they are trusting: administrator consoles, collaboration tools, package registries, marketplaces, support systems, or internal approval workflows. If an application treats visual appearance as irrelevant, an attacker may be able to register an identifier that resembles a trusted account closely enough to mislead another user. The database still sees two distinct strings. The human may not.

Cybersecurity 09 Sep 2026 9 min read

Design Security Notifications as Alerts, Not Authentication

A security notification can help a user notice that something important happened to an account: a password changed, a new authenticator was added, a recovery address changed, or a new session appeared. The notification is useful because it creates a second observation path outside the action that caused the event. That benefit can disappear if the notification itself becomes an authentication shortcut. A convenient link that immediately reverses a sensitive change may effectively become a bearer credential: anyone who obtains the link can exercise the authority embedded in it.

Cybersecurity 09 Sep 2026 10 min read

Design Push MFA to Resist Prompt Fatigue

Push-based multi-factor authentication can make sign-in convenient: after a password is accepted, the user receives a prompt on a trusted device and approves the attempt. The weakness appears when the prompt itself becomes easy to approve without understanding what it represents. If an attacker obtains a password and can repeatedly trigger approval requests, the legitimate user may eventually approve one because the prompts are confusing, disruptive, or mistaken for a request they initiated. The second factor still exists, but its security value has been reduced to a repeated yes-or-no question.

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.