Skip to main content

Knowledge Domain Database - Web Cybersecurity

How does the domain work before writing a line of code? Choose a document from the left tree: each page explains part of the model.

Business Rules - Cybersecurity Web

This document lists the fundamental business rules of the Cybersecurity Web domain, identified with a unique BR-NNN code. Each rule is technology-independent and describes an invariant constraint on the behaviour of the application-security system.

---

BR-001 - Input validation at every trust boundary

Code: BR-001 Name: Every input from an untrusted source must be validated before use Description: Data from clients, external APIs, uploaded files or broker messages must be validated against an explicit schema (type, length, format, range) before being processed, persisted or reflected in output. Server-side validation is mandatory even when the frontend already validates. Motivation: Prevent Injection, XSS and corruption of application state; no external input is trusted (defence in depth). Priority: CRITICAL Actors: Security Analyst, IDS/SIEM System Violation: request rejected with 400 Bad Request; ControlFailed event if bypassed validation produces a DetectedIncident. Traceability: OWASP Top 10 A03:2021 Injection; glossary "Parameterised query", "Output encoding".

---

BR-002 - Mandatory contextual output encoding

Code: BR-002 Name: Every dynamic value reflected in a response must be encoded for its destination context Description: Data interpolated into HTML, attributes, JavaScript, URLs or CSS must pass through a context-specific encoder. No untrusted data may be concatenated directly into the DOM or templates without escaping. Motivation: Neutralise reflected, stored and DOM-based XSS. Priority: CRITICAL Actors: Security Analyst, Penetration Tester Traceability: OWASP A03:2021; glossary "Cross-Site Scripting (XSS)", "DOM-based XSS", "Content Security Policy (CSP)".

---

BR-003 - Least privilege on every resource

Code: BR-003 Name: Every access Control grants the minimum privilege necessary for the operation Description: An authenticated subject receives only the permissions strictly necessary for the current task. Authorisation is verified at object level to prevent IDOR/BOLA: knowing an identifier does not imply the right to access it. Motivation: Limit the blast radius of a compromised credential; prevent Broken Access Control. Priority: CRITICAL Actors: CISO, Security Analyst Violation: HTTP 403 Forbidden; AlertGenerated event on repeated attempts. Traceability: OWASP A01:2021 Broken Access Control; glossary "Least privilege", "Broken Object Level Authorization (BOLA)", "IDOR".

---

BR-004 - Encryption in transit and at rest for sensitive data

Code: BR-004 Name: Sensitive data travels only over TLS 1.2+ and is encrypted at rest Description: No communication carrying credentials, tokens or personal data may occur in clear text. TLS 1.2 is the minimum, TLS 1.3 preferred; HSTS is mandatory. Persisted sensitive data is encrypted at rest with keys managed separately. Motivation: Protect confidentiality and integrity of data; prevent interception and token theft. Priority: CRITICAL Actors: CISO, Security Analyst Traceability: OWASP A02:2021 Cryptographic Failures; glossary "TLS", "HTTP Strict Transport Security (HSTS)", "Encryption at rest".

---

BR-005 - Rate limiting on sensitive endpoints

Code: BR-005 Name: Login, password reset and public APIs must apply rate limiting Description: Endpoints exposed to abuse (authentication, search, public APIs) apply a frequency limit per (client, endpoint). Exceeding it returns 429 Too Many Requests and an alerting event. Motivation: Mitigate brute-force, credential stuffing and Denial-of-Service attacks. Priority: HIGH Actors: IDS/SIEM System, Security Analyst Violation: 429 Too Many Requests + Retry-After header; AlertGenerated event. Traceability: OWASP A07:2021 Identification and Authentication Failures; glossary "Rate limiting", "Brute-force attack".

---

BR-006 - Secure session and token management

Code: BR-006 Name: Session tokens must be protected, rotated and revocable Description: Session cookies use the Secure, HttpOnly, SameSite attributes. Tokens are short-lived, regenerated on privilege change (anti session-fixation) and revocable. Client storage follows secure practices for the token type. Motivation: Prevent session hijacking, fixation and token theft via XSS. Priority: HIGH Actors: Security Analyst, CISO Traceability: OWASP A07:2021; glossary "Session management", "Session fixation", "SameSite cookie", "Secure cookie attributes", "Token storage".

---

BR-007 - Timely vulnerability triage and remediation

Code: BR-007 Name: Every detected Vulnerability must be classified and mitigated within a severity-based SLA window Description: A detected vulnerability receives a CVSSScore and a SeverityRating. The remediation window depends on severity: CRITICAL within 24–72 hours, HIGH within 7 days, MEDIUM within 30 days. The mitigation is verified before closure. Motivation: Reduce the exposure window (mean-time-to-remediate); prioritise by real risk. Priority: HIGH Actors: Security Analyst, CISO, Penetration Tester Traceability: CVSS v3.1; glossary "Threat modeling"; state-machines/vulnerability-lifecycle.md.

---

BR-008 - Notification and containment of confirmed incidents

Code: BR-008 Name: A confirmed breach triggers immediate containment and notification within regulatory deadlines Description: When a DetectedIncident is confirmed as a breach, the containment Control is activated without delay and notification to affected parties/authorities occurs within the applicable regulatory window (e.g. 72 hours under GDPR). Evidence is preserved for forensic analysis. Motivation: Limit breach impact and meet notification obligations. Priority: CRITICAL Actors: CISO, Security Analyst, IDS/SIEM System Traceability: GDPR Art. 33 (notification within 72 hours); glossary "Supply chain attack"; events/domain-events.md event BreachConfirmed.