Prepare for University Studies & Career Advancement

Web Security

As digital infrastructure continues to expand, the significance of network security becomes foundational to all forms of web activity. Web security, as a focused domain, encompasses a broader defense strategy that also draws insights from allied fields such as telecommunication systems and standards and wireless and mobile communications, where the secure transfer of data plays a critical role.
Robust web platforms require foundational knowledge of software development practices, including secure coding conventions and continuous integration techniques. With the proliferation of interconnected devices, embedded systems and IoT development has introduced new vulnerabilities that require dedicated countermeasures. Additionally, principles from HCI and UX shape secure authentication workflows and reduce user-induced risk.
Applications ranging from mobile apps to full-scale platforms are written in languages governed by different programming paradigms, each with its own security implications. Secure architectures are not accidental—they stem from thoughtful software architecture and design, refined through software engineering principles, maintained via continuous evolution, and validated by software testing and QA.
In the domain of web development and design, secure data flows rely on coordinated efforts between back-end development, secure CMS platforms, and resilient e-commerce systems. Security must be integrated from the front-end through to full-stack to address risks holistically.
Search engines increasingly reward secure sites, aligning SEO strategies with cybersecurity. Analytical tools like web analytics help detect anomalies and breaches in user behavior, while good web design reinforces user trust. Developers can streamline protective implementations using modern web development tools within structured performance optimization workflows.
Web security remains a living, evolving field, impacted by changes in web technologies and trends. As threats adapt, security professionals and developers must stay updated and proactive in deploying layered defenses to protect both infrastructure and users.
Web Security: protecting websites through scanning, hardening, and continuous monitoring.
Web Security: protecting websites through scanning, hardening, and continuous monitoring.
This image presents web security as an active, multi-layered defense system. The central shield-and-lock symbol represents protecting user accounts, databases, and core application services. Surrounding interface panels suggest essential defensive practices: scanning for OWASP vulnerabilities, applying security patches, configuring OAuth/JWT authentication, and monitoring network traffic for anomalous behavior.

Web Architecture & Web Security Navigation

Discover how web security protects every technical layer across the Web Development and Design cluster. Each card details threat vector mitigation, input validation boundaries, encryption protocols, and defensive access controls.

Web Development Overview

Provides the high-level system framework, mapping out how security policies, SSL/TLS handshake protocols, and firewall perimeters protect end-to-end client-server interactions.

Web Security

Focuses on OWASP Top 10 vulnerabilities (SQLi, XSS, CSRF), TLS 1.3 encryption, OAuth 2.0/JWT authentication, Web Application Firewalls (WAF), secure HTTP headers, and penetration testing.

Front-End Development

Examines DOM-based Cross-Site Scripting (XSS) prevention, context-aware output escaping, Content Security Policy (CSP) implementation, and secure cookie attribute configuration (HttpOnly, SameSite).

Back-End Web Development

Details server-side defenses against SQL injection using parameterized ORM queries, bcrypt password hashing, stateless JWT signature verification, CORS permissions, and rate-limiting middleware.

Full-Stack Development

Bridges multi-layer security, managing unified authentication tokens between client Single Page Applications (SPAs) and microservice API backends while isolating secret .env keys.

Web Development Tools

Covers automated security tooling, static code analysis scanners (SAST), dependency vulnerability auditors (npm audit, Snyk), and local HTTPS certificate utilities (mkcert).

Web Technologies

Explores cryptographic transport protocols, including TLS 1.3 handshake negotiation, HTTP Strict Transport Security (HSTS), DNSSEC, and secure WebSocket (wss://) channels.

Web Design

Integrates visual trust signals into UI layouts, designing clear multi-factor authentication (MFA) prompts, explicit permission dialogs, secure checkout trust badges, and cookie consent banners.

Content Management Systems (CMS)

Focuses on hardening administrative login endpoints, enforcing role-based access control (RBAC), auditing third-party plugin source codes, and applying security patch management.

E-Commerce Development

Applies strict Payment Card Industry Data Security Standards (PCI-DSS), tokenizing sensitive credit card payloads and establishing secure webhooks for payment processing.

Web Performance Optimisation

Balances security enforcement overhead against load times, optimizing TLS 1.3 session resumption, OCSP stapling, and Content Security Policy directive parsing.

Web Analytics

Enforces global privacy compliance (GDPR, CCPA), implementing IP address anonymization, secure first-party cookie limits, and consent-mode telemetry pipelines.

SEO (Search Engine Optimization)

Protects search indexation and domain authority by enforcing site-wide HTTPS encryption, preventing malware domain blacklisting, and blocking malicious spam injection attacks.

Common Vulnerabilities & Attack Vectors

Securing web platforms requires recognizing primary attack methodologies defined by the Open Web Application Security Project (OWASP):
  • SQL Injection (SQLi): Occurs when untrusted user input is concatenated directly into SQL database queries, allowing attackers to read, manipulate, or destroy database records.
Code Example — Vulnerable SQL vs. Parameterized Defense
-- Vulnerable Query (Malicious input: ' OR '1'='1)
SELECT * FROM users WHERE username = 'admin' OR '1'='1';

-- Secure Parameterized Query (Node.js pg module)
const query = 'SELECT * FROM users WHERE username = $1 AND password_hash = $2';
await db.query(query, [userInputUsername, hashedInputPassword]);
  • Cross-Site Scripting (XSS): Injects malicious client-side JavaScript into pages viewed by other users.
    • Stored XSS: Malicious payload is permanently saved in a database (e.g., in a comment field) and served to subsequent visitors.
    • Reflected XSS: Script payload is bounced off an HTTP request parameter directly onto the response view.
    • Prevention: Context-aware HTML escaping, adopting frameworks with auto-escaping (React, Vue), and deploying Content Security Policy (CSP) headers.
  • Cross-Site Request Forgery (CSRF): Exploits user browser trust to trick authenticated users into executing unwanted state-changing actions (e.g., changing passwords or transferring funds) on target sites.
    • Prevention: Cryptographic CSRF anti-forgery tokens, setting SameSite=Strict or SameSite=Lax on session cookies, and validating Origin headers.

Cryptographic Encryption & Transport Layer Security

Cryptography protects data integrity and privacy across public network channels and persistent storage:
  • HTTPS & TLS 1.3: HyperText Transfer Protocol Secure encrypts all client-server communication using Transport Layer Security (TLS). TLS 1.3 eliminates legacy cipher suites, reduces handshake overhead to a single roundtrip, and enforces forward secrecy.
  • Data at Rest & Password Hashing:
    • Database Field Encryption: Encrypting sensitive data at rest using AES-256 block ciphers.
    • Cryptographic Password Hashing: Raw passwords must never be stored plain-text or encrypted reversibly. Applications must use salted, computationally expensive hashing functions such as Argon2id or bcrypt to resist GPU brute-force attacks.

Authentication Protocols & Identity Management

Verifying user identity and enforcing authorization permissions at application boundaries:
  • OAuth 2.0 & OpenID Connect (OIDC): OAuth 2.0 delegates scoped resource authorization to third-party providers (e.g., “Sign in with Google”). OpenID Connect adds an identity layer on top of OAuth 2.0 to deliver user profile claims safely.
  • JSON Web Tokens (JWT): Digitally signed, stateless authorization tokens containing user claims passed via HTTP headers (Authorization: Bearer <token>).
  • Multi-Factor Authentication (MFA): Enforces secondary verification steps beyond passwords, utilizing Time-based One-Time Passwords (TOTP via authenticator apps) or FIDO2 hardware tokens (YubiKey).

Web Application Firewalls (WAF) & Security Headers

Edge defense systems and response headers establish a protective layer around application runtimes:
  • Web Application Firewalls (WAF): Reverse proxy services (Cloudflare WAF, AWS WAF, Imperva) inspecting inbound HTTP traffic to block malicious SQLi, XSS, and DDoS floods before they reach backend application servers.
  • Essential HTTP Security Headers:
    # Restricts external resource loading origins
Content-Security Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com

# Prevents clickjacking by blocking iframe embedding
X-Frame-Options: DENY

# Forces browser to strictly respect declared MIME types
X-Content-Type-Options: nosniff

# Enforces HTTPS connections for 1 year
Strict-Transport-Security: max-age=31536000; includeSubDomains

Why Study Web Security

Mastering web security is essential for building trustworthy software and protecting digital assets:
  • Critical Risk Prevention: Prevents costly data breaches, customer identity theft, financial liability, and reputational damage.
  • Regulatory & Legal Compliance: Guarantees applications meet mandatory legal frameworks, including GDPR, CCPA, and PCI-DSS standards.
  • High Industry Demand: Security expertise is a critical requirement across full-stack development, application security engineering, DevOps, and cloud architecture.

Engineering FAQs: Application Security & Cryptography

Why are Prepared Statements (Parameterized Queries) effective against SQL Injection?

Prepared statements separate the SQL code structure from the user-supplied parameters. The database driver compiles the SQL query command first, treating parameters strictly as literal data values rather than executable code instructions, making payload injection impossible.

What is the difference between Authentication and Authorization?

Authentication verifies *who a user is* (e.g., checking credentials during login). Authorization determines *what resources or actions that authenticated user is permitted to access* (e.g., verifying if an authenticated user has Admin role permissions to delete a database entry).

How do the HttpOnly and Secure cookie flags protect user session tokens?

The HttpOnly flag blocks client-side JavaScript scripts from accessing the cookie via document.cookie, mitigating session token theft via Cross-Site Scripting (XSS). The Secure flag restricts the cookie to encrypted HTTPS requests only, preventing clear-text transmission.

What is the role of a Salt in cryptographic password hashing?

A salt is a unique, random string appended to each user’s password before hashing. Salting ensures that identical plain-text passwords produce completely distinct hash values in the database, invalidating pre-computed rainbow table lookup attacks.

How does a Content Security Policy (CSP) header mitigate XSS vulnerabilities?

A CSP header provides an explicit whitelist of trusted domain origins from which the browser is allowed to load and execute scripts. It blocks inline JavaScript execution (<script>...</script>) and unapproved third-party domain downloads automatically.

Interactive Knowledge Verification & Practice Problems

Quick Check: Web Security Core Concepts

1. What is the primary cause of SQL Injection vulnerabilities?
Answer: SQL Injection occurs when untrusted user inputs are concatenated directly into raw database query strings without input parameterization or sanitization.
2. What security protection does the SameSite=Strict cookie attribute provide?
Answer: SameSite=Strict prevents the browser from sending the session cookie on cross-site requests (links or forms originating from external domains), providing strong protection against Cross-Site Request Forgery (CSRF) attacks.
3. Why are slow hashing algorithms (e.g., bcrypt or Argon2) required for password storage instead of fast MD5 or SHA-256?
Answer: Fast cryptographic functions like SHA-256 allow attackers to compute billions of guesses per second on modern GPUs during a database breach. Slow hashing algorithms incorporate work factors to make automated brute-force attacks computationally infeasible.
4. What is the difference between Stored XSS and Reflected XSS?
Answer: Stored XSS saves a malicious script permanently inside a backend database to execute against future visitors. Reflected XSS reflects the script immediately off an HTTP request parameter onto a single user’s response page.

Thought-Provoking Application Security Questions

1. How does Stateless JWT Authentication differ from Session-Based Cookie Authentication?
Answer: Session authentication stores stateful user session records in server RAM or Redis, issuing a random session ID cookie. JWT authentication is stateless: user claims are encoded into a digitally signed token stored on the client, which the server validates cryptographically without database lookups.
2. What vulnerabilities arise when developers store secret API keys directly inside front-end JavaScript bundles?
Answer: All client-side JavaScript files sent to browsers are public. Storing secret API credentials in client code allows attackers to extract keys via browser inspection tools and abuse backend third-party APIs or infrastructure under the merchant’s account.
3. How does CORS (Cross-Origin Resource Sharing) enforce browser security boundaries?
Answer: CORS is a browser security mechanism that uses HTTP headers (e.g., Access-Control-Allow-Origin) to restrict web applications running on one domain from making unauthorized asynchronous API requests to a backend API running on a different domain.

Numerical Engineering Problems & Solutions

Problem 1: Bcrypt Password Hashing Work Factor & Server Load Calculation
A backend server receives 50 login requests per second. Calculating a bcrypt hash at cost factor 12 requires 250 ms of CPU processing time on a single core. Calculate the minimum number of dedicated server CPU cores required to handle peak login traffic without creating a request backlog.
Solution:
  1. Convert execution time to seconds: 250 ms = 0.25 seconds per login
  2. Calculate total CPU processing time required per second: 50 requests/sec × 0.25 seconds = 12.5 CPU core-seconds per second
  3. Number of CPU cores required: 12.5 cores → round up to handle concurrency = 13 CPU cores
Answer: The server cluster requires a minimum of 13 CPU cores dedicated to password hashing processing.
Problem 2: Rate-Limiting Protection Against Brute-Force Password Attacks
An un-throttled login endpoint allows an attacker to execute 1,000 automated password attempts per second. Implementing an IP-based rate-limiting rule (maximum 5 failed login attempts per minute per IP address) restricts the attack. Calculate the maximum number of password attempts an attacker can send per hour from a single IP address and the percentage reduction in attack throughput.
Solution:
  1. Un-throttled attack rate per hour: 1,000 attempts/sec × 3,600 seconds = 3,600,000 attempts/hour
  2. Rate-limited attack rate per hour: 5 attempts/minute × 60 minutes = 300 attempts/hour
  3. Attempts eliminated per hour: 3,600,000 – 300 = 3,599,700 attempts eliminated
  4. Percentage throughput reduction: (3,599,700 / 3,600,000) × 100 = 99.99166…%
Answer: The rate limit caps attempts at 300 per hour, achieving a 99.99% reduction in attack traffic.
Problem 3: WAF Automated Attack Filtering & Server Bandwidth Savings
A web server processes 1,500,000 incoming HTTP requests per day, with each request payload averaging 80 KB. Deploying a Cloudflare Web Application Firewall (WAF) identifies and blocks 35% of incoming traffic as malicious bot scans and SQLi attempts at the edge network layer. Calculate the daily and monthly bandwidth saved at the origin server in gigabytes (GB) assuming a 30-day month.
Solution:
  1. Malicious requests blocked per day: 1,500,000 × 0.35 = 525,000 requests
  2. Daily bandwidth saved: 525,000 requests × 80 KB = 42,000,000 KB
  3. Convert daily savings to Megabytes (1 MB = 1,000 KB): 42,000,000 / 1,000 = 42,000 MB
  4. Convert daily savings to Gigabytes (1 GB = 1,000 MB): 42,000 / 1,000 = 42 GB per day
  5. Monthly bandwidth saved (30 days): 42 GB × 30 = 1,260 GB (1.26 TB)
Answer: Edge WAF filtering saves 42 GB of origin bandwidth per day and 1,260 GB (1.26 TB) per month.
Problem 4: Password Entropy & Brute-Force Combination Calculation
A system switches from enforcing an 8-character numeric PIN (digits 0–9) to requiring a 12-character alphanumeric password using upper/lowercase letters and digits (62 possible characters). Calculate the total possible key space combination count for both standards and the factor increase in key space complexity.
Solution:
  1. Original key space (10 options ^ 8 length): 10^8 = 100,000,000 (100 million combinations)
  2. New key space (62 options ^ 12 length): 62^12 ≈ 3.226 × 10^21 combinations
  3. Complexity factor increase: (3.226 × 10^21) / (1 × 10^8) ≈ 3.226 × 10^13 times larger
Answer: The key space increases from 100 million to approximately 3.23 × 10^21 combinations (over 32 trillion times larger).
Problem 5: TLS 1.2 vs. TLS 1.3 Handshake Latency Optimization
A legacy TLS 1.2 handshake requires 2 full network Round-Trip Times (2 RTT) to complete cryptographic negotiation, whereas TLS 1.3 reduces the handshake to 1 Round-Trip Time (1 RTT). If cross-continental network latency between client and server is 120 ms per RTT, calculate the connection setup time for both protocols and the net time saved per initial HTTPS connection.
Solution:
  1. TLS 1.2 Handshake Setup Time (2 RTT): 2 × 120 ms = 240 ms
  2. TLS 1.3 Handshake Setup Time (1 RTT): 1 × 120 ms = 120 ms
  3. Net latency time saved per connection: 240 ms – 120 ms = 120 ms
Answer: TLS 1.3 reduces connection setup latency from 240 ms to 120 ms (saving 120 ms per secure handshake).

Core Documentation & External References

Web Security — Learning & Wrap-Up

Summary

  • Defensive Coding Rules: Eliminate SQL injection and XSS through parameterized database queries, context-aware output escaping, and CSP headers.
  • Cryptographic Transport Security: Enforce HTTPS encryption using TLS 1.3, salted password hashing (Argon2id/bcrypt), and data-at-rest encryption.
  • Robust Identity Verification: Implement stateless JWT authorization tokens, OAuth 2.0 multi-factor authentication (MFA), and secure cookie attributes.
  • Edge Firewall Protection: Deploy Web Application Firewalls (WAF) and automated static dependency scanners to block threats prior to runtime execution.
Last updated: 21 Jul 2026