Keleigh Berenger, Research and Development Engineer, Surrey Centre for Cyber Security & Member of the UK Cyber Security Council's Expert Volunteer Panel

I’ve spent a good part of my career working in start-up environments, the kind where “ship it fast” is often the unspoken motto. It’s an exciting rhythm until you realize how easily security becomes an afterthought. In that rush to deliver, we sometimes forget that every shortcut we take can quietly introduce risks that later become impossible to climb out of. Once those cracks appear in your foundation, patching them costs more than time, it can cost the product and the trust that sustains it.

That’s why this piece dives into the small but critical details, the nitty gritty of what we, as developers, can do differently. I often say that each of us is the first line of defense, no matter our role. And in the world of web and application security, that’s especially true for those of us who love to build, break, and rebuild our systems in the pursuit of something better.

But before we get into exploits and mitigations, let’s pause to consider a concept at the heart of all security: trust. We have to ask ourselves some uncomfortable questions.

Do we trust that every input reaching our backend is exactly what the user intended to send? Do we trust that all third‑party scripts and libraries loaded in the browser behave as expected? Do we trust that our APIs will only ever be called by our own frontend? Make some notes, question the system and, with that foundation in mind, let’s unpack some of the common attack vectors and the practices that help keep our applications standing strong.

Input and output validation

When it comes to input handling, the safest route is to assume everything is hostile until proven otherwise. Unwanted or unknown inputs shouldn’t be “handled gracefully”, they should be rejected outright. The most robust pattern is positive validation (whitelisting), which defines strictly what is allowed, rather than trying to block what isn’t. Negative validation (blacklisting) can supplement this, but it’s reactive and easy to bypass as attackers find new payloads or encoding tricks. Developers often rely on sanitization, but that’s really a last‑resort safety net, not a substitute for validation.

The danger of mishandling inputs, especially when untrusted data gets echoed back to the user, is that it opens the door to Cross‑Site Scripting (XSS) and other injection attacks. For instance, if an attacker submits a script tag that’s reflected in an error message or search result, the browser may execute that code in the context of your site, allowing credential theft, session hijacking, or data exfiltration. Even something as simple as returning “Invalid input: <user data>” can leak execution context or system details that improve an attacker’s aim. That’s why careful wording matters: error responses should be short, generic, and free of user‑supplied content. Security isn’t just in your code logic, it’s in every message your system sends back.

On the output side, the same caution applies, if your application displays or processes data originating from untrusted sources, you must treat it as potentially dangerous. This is where output encoding becomes essential. Unlike sanitization, encoding ensures that potentially unsafe characters (like <, >, or ') are rendered harmless for the given context, whether that’s HTML, JavaScript, or a database query. Without proper encoding, even legitimate data can become a conduit for cross‑site scripting or injection attacks once it’s displayed in the user’s browser. Just as important is using secure, up‑to‑date frameworks that handle encoding automatically and follow modern security practices; outdated or unsafe frameworks often fail to apply these protections consistently. In short, never trust outgoing data any more than incoming, every output path is a potential exploit path if handled carelessly.

Databases and storage

When it comes to databases and data storage, one of the leading causes of breaches is the mixing of data and commands, a mistake that still fuels SQL injection attacks to this day. This happens when user input is directly concatenated into database queries instead of being treated as data. The safest pattern is to bind parameters using prepared statements, which cleanly separate logic from input and neutralize most injection attempts. This principle applies not only to traditional SQL databases but also to NoSQL systems, where injection can occur through query objects or improperly handled operators. Always choose trusted, well‑maintained database engines, and take the time to review vendor documentation for known loopholes or security advisories, many issues stem from insecure defaults that go unnoticed.

For storing sensitive information, the rule of thumb is simple: if you don’t truly need it, don’t store it. If you must, store it safely, use strong hashing algorithms with a unique salt per entry to protect passwords or similar data. Algorithms like bcrypt and scrypt remain industry standards because they’re slow and adaptive, making brute‑force attacks much harder. The salt length is equally crucial; a long, random salt ensures no two hashes collide, even if the original passwords match. In secure design, how you store data often matters as much as how you protect access to it, both must be deliberate, cautious decisions.

Browser Security and Session Management

When dealing with browser security and session management, encryption and control are everything. Always serve your application over HTTPS, not just on login pages but across the entire site. This ensures that data in transit, from credentials to cookies, is protected against interception. Your SSL/TLS certificates should come from a trusted Certificate Authority, and wherever possible, enable HTTP Strict Transport Security (HSTS) to enforce HTTPS and prevent downgrade attacks.

For session cookies, configure them with the Secure and HttpOnly flags to prevent client‑side access via scripts, and apply the SameSite attribute to limit cross‑origin requests. Clearly define paths and domains for cookies so the browser knows where they’re valid, reducing exposure to unrelated or malicious endpoints. Avoid embedding sensitive data in URLs, since URLs are logged, cached, and easily exposed. Add CSRF tokens to critical actions to prevent unauthorized requests, and introduce session timeouts or inactivity timers to mitigate stolen or abandoned sessions.

Users should also be protected against tab‑nabbing, an attack in which a newly opened browser tab gains control of the original window and redirects it to a malicious site. This risk can be mitigated by configuring external links with the rel="noopener noreferrer" attribute. In addition, session fixation, where an attacker compels a victim to use a predetermined session identifier, should be prevented by regenerating session tokens after authentication or whenever user privileges change. Ultimately, robust browser and cookie security controls are not mere implementation details; they establish the boundary between a trustworthy authentication process and one that can be trivially compromised.

Authentication and Authorization

When trust is distributed across multiple systems, such as third‑party identity providers, the question becomes: how much confidence can you place in their infrastructure and implementation? Using external authentication services or single sign‑on (SSO) solutions improves usability but also introduces dependencies and shared risk. Developers should enforce layered protection even when delegating sign‑ins, for example, by requiring multi‑factor authentication (2FA), supporting JWT‑based access tokens with refresh tokens, and ensuring token lifecycles align with the application’s trust model.

While SSO simplifies the user experience, overreliance on a single identity reused across multiple systems can amplify the impact of a compromise. Enabling regular password rotation, secure password resets, and two‑factor authentication adds resilience. Applications should also conceal user existence by returning generic error messages during login or account recovery.

To limit brute‑force attacks, implement temporary account lockouts after several consecutive failed attempts. However, design this control carefully. A mechanism that locks users indefinitely or requires administrative intervention can be exploited to trigger denial‑of‑service conditions or to enumerate valid usernames. Short lockouts with CAPTCHA challenges are ideal to deter automated attacks without significantly affecting legitimate users.

Never use default or hard‑coded credentials, even for debugging or staging, as they often leak into production environments and remain a critical vector in real‑world breaches.

Moving from authentication to authorization, this stage governs who can perform specific actions on given resources, those resources may be pages, APIs, files, or even system‑level components. In practice, authorization often operates across two dimensions: global permissions, which apply system‑wide (e.g., administrator roles), and resource‑level permissions, which control access to individual objects or datasets. Sound authorization design relies on policy‑based mechanisms like Role‑Based Access Control (RBAC) or Attribute‑Based Access Control (ABAC), allowing behavior to be evaluated against clear rules rather than ad hoc code checks. Establishing these models early in design ensures consistent, auditable enforcement of privilege boundaries. There are other models as well, it depends on what suits the situation.

Addressing Zero‑Day Vulnerabilities and Availability Threats

Even the most carefully built systems face the unexpected, zero‑day vulnerabilities, the flaws that are exploited before patches are available. The only real defense is vigilance and layered design. Developers should understand the software components they depend on, from frameworks to third‑party libraries, and continuously monitor for advisories and dependency updates. Maintain an inventory of what’s running in your environment, because you can’t patch what you don’t know exists. Regular code reviews and cleanup also matter: removing unused components and deprecated functions reduces your attack surface before it can be weaponized.

Patch management forms the first line of defense against known exploits. Staying current with fixes for your libraries, frameworks, and dependencies prevents attackers from taking advantage of published vulnerabilities. Automating these updates where possible helps, but always test before deployment to avoid introducing instability. When exposure is unavoidable, compensating controls such as Web Application Firewalls (WAFs) can help detect and filter malicious traffic, particularly during API transactions or when perimeter controls are your primary shield.

On the availability front, unregulated traffic can lead to DoS or DDoS conditions. To mitigate this, ensure your application stack uses load balancers, message queues, and rate‑limiting to distribute traffic and preserve system responsiveness. Handle gateway timeouts and error responses gracefully, provide minimal, generic output that reveals nothing about your infrastructure or failure modes. The smallest configuration detail can either leak valuable intelligence or quietly strengthen your defense.

In the end, these are only the first steps toward a mature security posture. The principles of constant review, rapid patching, and resilient design form the groundwork. As the threat landscape evolves, remember, this is just the tip of the iceberg, but it’s the right path to start on.