Skip to main content
Knowledge Hub

Web Security Threat Models

Understanding common web security threats and how to defend against them

Last updated: December 7, 2024

Web Security Threat Models

Understanding threats helps you build appropriate defenses. Security is not about eliminating all risks, but about understanding what you’re protecting against and implementing appropriate countermeasures.

This article explores common web security threats, how they work, and practical defenses you can implement in your applications.

Injection Attacks

Injection attacks occur when malicious input is interpreted as code or commands. The most common types are SQL injection, NoSQL injection, command injection, and code injection.

SQL injection happens when user input is directly concatenated into SQL queries without proper escaping. Attackers can manipulate queries to read, modify, or delete data.

NoSQL injection targets databases like MongoDB that use JavaScript-like query syntax. Attackers can inject operators that change query behavior.

Command injection occurs when user input is executed as system commands. This is particularly dangerous as it can give attackers full system access.

Defenses include using parameterized queries, input validation, output encoding, and principle of least privilege. Never trust user input, always validate and sanitize, and use prepared statements or query builders that handle escaping automatically.

Cross-Site Scripting

Cross-Site Scripting, or XSS, occurs when malicious scripts are injected into web pages viewed by other users. There are three main types: stored XSS, reflected XSS, and DOM-based XSS.

Stored XSS happens when malicious scripts are saved to the database and executed when other users view the content. Reflected XSS occurs when malicious scripts are reflected off the server in responses. DOM-based XSS happens when client-side JavaScript manipulates the DOM unsafely.

XSS attacks can steal session cookies, redirect users to malicious sites, deface websites, or perform actions on behalf of users.

Defenses include output encoding, Content Security Policy headers, input validation, and using frameworks that automatically escape output. Always encode user-generated content before displaying it, and use Content Security Policy to restrict which scripts can execute.

Cross-Site Request Forgery

Cross-Site Request Forgery, or CSRF, tricks users into making unwanted requests to sites where they’re authenticated. Attackers create malicious pages that submit forms or make requests to the target site using the user’s session.

CSRF attacks can change user settings, transfer funds, or perform other state-changing operations on behalf of authenticated users.

Defenses include CSRF tokens, SameSite cookie attributes, checking referer headers, and requiring re-authentication for sensitive operations. CSRF tokens ensure that requests originate from your application, not from malicious sites.

Authentication and Session Management Vulnerabilities

Weak authentication mechanisms can allow unauthorized access. Common vulnerabilities include weak passwords, password reuse, session fixation, and insecure session storage.

Session hijacking occurs when attackers steal session identifiers. This can happen through XSS, network interception, or predictable session IDs.

Defenses include strong password requirements, secure password storage with hashing and salting, secure session management, HTTPS for all authentication, and multi-factor authentication. Use secure, random session identifiers and store them securely.

Insecure Direct Object References

Insecure direct object references occur when applications expose internal implementation details like database keys, file paths, or other identifiers. Attackers can manipulate these to access unauthorized resources.

For example, if user IDs are sequential, an attacker might try accessing other users’ data by incrementing the ID.

Defenses include access control checks, using indirect references like UUIDs instead of sequential IDs, and validating that users have permission to access requested resources. Never rely on obscurity for security, always verify permissions.

Security Misconfiguration

Security misconfiguration includes default credentials, unnecessary features enabled, error messages revealing sensitive information, and missing security headers.

Default credentials are a common problem. Many systems ship with well-known default passwords that are never changed.

Unnecessary features increase attack surface. Disable features you don’t use, and keep software updated.

Error messages can leak sensitive information like stack traces, database structure, or file paths. Provide generic error messages to users while logging detailed information server-side.

Missing security headers leave applications vulnerable. Use security headers like Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security.

Sensitive Data Exposure

Sensitive data exposure occurs when applications don’t adequately protect sensitive information like passwords, credit card numbers, or personal data.

Data can be exposed through insufficient encryption, weak cryptographic algorithms, or storing sensitive data unnecessarily.

Defenses include encrypting sensitive data in transit and at rest, using strong cryptographic algorithms, minimizing data collection, and properly disposing of sensitive data. Never store sensitive data unless absolutely necessary, and if you must, encrypt it properly.

Missing Function Level Access Control

Missing function level access control occurs when applications don’t verify that users have permission to access functions or resources before allowing access.

This differs from insecure direct object references in that it’s about missing checks rather than exposed references.

Defenses include implementing access control checks at every function entry point, using role-based access control, and testing that unauthorized users cannot access restricted functions.

Using Components with Known Vulnerabilities

Using components with known vulnerabilities is a common problem. Third-party libraries and frameworks often have security vulnerabilities that are discovered and patched over time.

Defenses include keeping dependencies updated, monitoring security advisories, using dependency scanning tools, and minimizing the number of dependencies. Regularly update your dependencies and have a process for responding to security advisories.

Insufficient Logging and Monitoring

Insufficient logging and monitoring makes it difficult to detect and respond to security incidents. Without proper logging, attacks can go unnoticed.

Defenses include logging security-relevant events like authentication attempts, access control failures, and sensitive operations. Monitor logs for suspicious activity and have alerting in place for security events.

Security Best Practices

Implement defense in depth by using multiple layers of security. No single security measure is sufficient on its own.

Follow the principle of least privilege. Users and systems should have only the minimum permissions necessary.

Validate input at the boundary. Check all user input as it enters your system, and encode output when displaying it.

Use secure defaults. Security should be the default, not an afterthought.

Keep software updated. Security patches are important, and outdated software is vulnerable.

Conduct security audits. Regularly review your security measures and test for vulnerabilities.

Summary

Understanding web security threats is the first step in building secure applications. By implementing appropriate defenses, following security best practices, and staying informed about new threats, you can significantly reduce the risk to your applications and users.

The key is to think like an attacker, understand how attacks work, and implement multiple layers of defense. Security is an ongoing process, not a one-time task.