Hartmut/CapaKraken
1
0
Fork 0
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

CDP 35948520: Web Application #25

New Issue
Open
opened 2026-04-16 08:16:52 +02:00 by Hartmut · 3 comments
Hartmut commented 2026-04-16 08:16:52 +02:00
Owner
Copy Link
Copy Source

CDP Control ID: 35948520
Category: Secure Application Development
Frequency: Biannually
Owner: h.noerenberg
Parent: #1

Requirement & Guidance

Secure Application Development Requirement: Complete ADM and CDP requirements for Web Application Security. Guidance: Confirm compliance through control validation questions. Additional information can be found on CDP website Secure Application Development

Sub-Validation Questions (Compliance-Status pro Frage markieren)

  • 1. Segregate application servers and databases that contain confidential data from the web-DMZ by placing them in an internal network zone. Deny direct Internet access to databases.
    ✅ PostgreSQL nur im Docker-Netz, keine Internet-Exposition (Compliance EAPPS 3.2.1.02/03).
  • 2. For Accenture hosted applications, web-based applications must use federated authentication (ADFS) using WS -PRP or SAML 2.0 protocol.
    ⚪ Interne App, nicht Accenture-hosted — Credentials + TOTP MFA statt ADFS/SAML.
  • 3. Webservice and webservice definition language (wsdl) must enforce authentication via alternate endpoints using transport layer authentication mechanisms like windows authentication or basic authentication over TLS.
    ⚪ Kein SOAP/WSDL — ausschließlich tRPC/REST.
  • 4. To enable the web application front-end to connect to the database, create an active directory account (AD) for the application and configure this account to the database server using window integrated authentication.
    ⚪ Keine Windows Active Directory-Integration — PostgreSQL-User mit ENV-Passwort.
  • Where use of AD account is not possible, the database connection credentials must be encrypted within a configuration file using 3DES or stronger encryption algorithms. The configuration file should be accessible only by authorized system administrators.
    ✅ DB-Credentials in ENV (DATABASE_URL), nicht in Config-Files; .env in .gitignore.
  • 5. Implement efficient input validation object into coding.
    ✅ Zod-Schemas auf allen tRPC-Input-Pfaden.
  • Validate all inputs by the server-side code. Reject these characters:|, &, ; , $ , % , @ , ' , "" , ' , "" , <> , (), +, CR, LF, \
    ✅ Server-Validation via Zod; Prisma parameterized SQL verhindert Injection ohne Character-Rejection; DOMPurify sanitized Rich-Text.
  • For all input fields, forms, URLs and cookies in the application, only accept data from the end user or process that is expected.
    ✅ Typed I/O via Zod auf tRPC + Cookies als HttpOnly (kein Client-Write).
  • Perform validation against session variables and parameters (e.g. URL variables, hidden fields etc.)
    ✅ Session-State server-only (Auth.js), URL-Params via Next.js typed routes + Zod.
  • Ensure proper length limit on application parameters and URLs. Validate strings length, expected characters and pattern. Use regular expressions for validation as necessary.
    ✅ Zod .min()/.max() auf relevanten Feldern (Compliance EAPPS 3.2.2.3.03).
  • Reject inputs with potentially malicious characters. Sanitize input to exclude context-changing symbols such as apostrophe, quotes, etc.; as well as script characters such as < > "" ' % ; ) ( & + JavaScript: img
    ✅ DOMPurify auf Rich-Text; React escapt automatisch; Prisma parameterized SQL.
  • 6. Encode HTML input to prevent the client’s web browser from interpreting every users supplied input as executable code. Do not store sensitive data in cookies.
    ✅ React auto-escape in JSX; Sensitive Daten nicht in Cookies (HttpOnly Session-only).
  • 7. Use libraries (e.g., anti-cross site scripting library such as .Net AntiXSS Library) to protect against security bugs during web application development.
    ✅ DOMPurify auf User-Markdown/Rich-Text; React escapt alle String-Werte.
  • 8. Webdav should be left disabled, by default, if there is no business functionality that requires it.
    ✅ nginx Reverse Proxy, keine WebDAV-Konfiguration aktiviert.
  • 9. Apply pre-requisites before using http methods DELETE, PUT, OPTIONS, PATCH HEAD. Refer to the Application Security Standard. Disable Trace method
    ✅ tRPC nutzt nur GET/POST; andere Methoden nicht exposed (Compliance EAPPS 3.3.1.5.01).
  • 10. Use cookies securely:
    ✅ Parent — siehe Sub-Items.
  • Set the 'Secure' and 'Httponly' attributes in the cookie.
    ✅ auth.config.ts setzt httpOnly: true + secure: production + sameSite: strict auf allen Cookies.
  • Do not use the domain parameter unless you need to scope the cookie to other applications outside the current application.
    ✅ Kein domain Parameter gesetzt (Default = current host only).
  • Set the proper scope of the ‘path’ attribute.
    ✅ path: '/' — passend für Single-App-Deployment.
  • *For example, if the application resides at /myapp/, then set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp.
    ✅ Informational — nicht anwendbar bei Root-Deployment.
  • Establish Hard limits to the lifetime of authentication cookies. Do not set cookie expiration time unless a persistent cookie is required. Setting the expiration time changes a cookie from session to persistent and should be avoided where possible. In cases were a persistent cookie is a business requirement, limit the lifespan of the cookie to the shortest duration that meets the required business benefit.
    ✅ maxAge: 28800 (8h absolute), Session-basiert (kein persistent Cookie).
  • 11. Secure Cookie Content:
    ✅ Parent — siehe Sub-Items.
  • The cookie must be input validated;
    ✅ HttpOnly verhindert Client-Write; Server-Side liest nur getypte JWT-Claims.
  • If the cookie must not be modified by the user then it must be made tamper resistant with an HMAC or similar mechanism to protect integrity of cookie content.
    ✅ Auth.js JWT-Signature (HMAC-SHA256 mit AUTH_SECRET); Mismatch → Session ungültig.
  • If the user must not see the data in the cookie then it must also be encrypted.
    🟡 Session-Cookie ist signed (JWT), nicht encrypted. HttpOnly verhindert Einsicht via JS. Follow-up: Auth.js Encrypted-JWE evaluieren, falls sensitive Claims hinzukommen.
  • 12. Do not use sensitive parameters in the URL such as user id, sessionid and other sensitive parameters.
    ✅ Keine User-IDs/Session-IDs in URLs; tRPC nutzt POST-Body + Cookie-Session.
  • 13. For Silverlight or Flash components, specify trusted domains in the client access policy or crossdomain policy configuration file. Do not leave domain = *.
    ⚪ Kein Silverlight / Flash im Einsatz.
  • 14. Pages containing static sensitive data must not be cached.
    ✅ Cache-Control: no-store global + auf Auth-Seiten (Compliance EAPPS 3.3.1.7.01).
  • 15. Avoid using URL redirects and forwards. If this cannot be avoided, verify that the parameter(s) are validated to contain only an allowed destination.
    ✅ Auth.js callbackUrl wird gegen konfigurierte Base-URL validiert; keine Open-Redirects.
  • 16. Use HTTP POST-requests instead of HTTP GET-requests since all parameters will be found in the URL for a GET-request. In general, avoid transmitting passwords in URL. Use secure mechanisms instead, such as digital certificates for example for sending passwords.
    ✅ Login und Mutations über POST (tRPC + Auth.js); keine Credentials in Query-Strings.
  • 17. Create an inventory of all input fields, including Get parameters/hidden fields, and have these included in test scripts for input validation tests.
    🟡 Zod-Schemas sind im Code (einheitliche Quelle), aber kein aggregiertes Test-Input-Inventory-Dokument. Follow-up: Skript, das alle Zod-Schemas extrahiert und als Security-Test-Matrix ausgibt.
  • 18. Conduct a critical evaluation to the level of scrutiny over approval process of when/how applications are opened to the internet and confirm that the following are in place:
    🟡 Parent — siehe Sub-Items zu Change-Control-Prozess.
  • A structured change control review procedure to define two layers of review in advance of ports being opened to the internet.
    🟡 PR-Review + CI-Checks vorhanden (1 Layer). TODO: 2. Review-Layer für sicherheitskritische Änderungen (z. B. Auth, RBAC) dokumentieren.
  • Review procedure is documented in this control and communicated.
    🟡 docs/sdlc.md dokumentiert PR-Prozess. TODO: Explizite Security-Change-Review-Sektion ergänzen.
  • A ""final approver"" is identified.
    🟡 Repo-Owner ist de-facto Final-Approver (CODEOWNERS). TODO: Formal dokumentieren.
  • Changes and connections must be approved by qualified security teams.
    🟡 Kleines Team ohne dediziertes Security-Team. TODO: Bei Security-relevanten PRs externen Review einplanen (z. B. Accenture Security-Kontakt).
**CDP Control ID:** `35948520` **Category:** Secure Application Development **Frequency:** Biannually **Owner:** h.noerenberg **Parent:** #1 ## Requirement & Guidance Secure Application Development Requirement: Complete ADM and CDP requirements for Web Application Security. Guidance: Confirm compliance through control validation questions. Additional information can be found on CDP website Secure Application Development ## Sub-Validation Questions (Compliance-Status pro Frage markieren) - [x] 1. Segregate application servers and databases that contain confidential data from the web-DMZ by placing them in an internal network zone. Deny direct Internet access to databases. ✅ *PostgreSQL nur im Docker-Netz, keine Internet-Exposition (Compliance EAPPS 3.2.1.02/03).* - [x] 2. For Accenture hosted applications, web-based applications must use federated authentication (ADFS) using WS -PRP or SAML 2.0 protocol. ⚪ *Interne App, nicht Accenture-hosted — Credentials + TOTP MFA statt ADFS/SAML.* - [x] 3. Webservice and webservice definition language (wsdl) must enforce authentication via alternate endpoints using transport layer authentication mechanisms like windows authentication or basic authentication over TLS. ⚪ *Kein SOAP/WSDL — ausschließlich tRPC/REST.* - [x] 4. To enable the web application front-end to connect to the database, create an active directory account (AD) for the application and configure this account to the database server using window integrated authentication. ⚪ *Keine Windows Active Directory-Integration — PostgreSQL-User mit ENV-Passwort.* - [x] Where use of AD account is not possible, the database connection credentials must be encrypted within a configuration file using 3DES or stronger encryption algorithms. The configuration file should be accessible only by authorized system administrators. ✅ *DB-Credentials in ENV (`DATABASE_URL`), nicht in Config-Files; `.env` in `.gitignore`.* - [x] 5. Implement efficient input validation object into coding. ✅ *Zod-Schemas auf allen tRPC-Input-Pfaden.* - [x] Validate all inputs by the server-side code. Reject these characters:|, &, ; , $ , % , @ , ' , "" , \' , \"" , <> , (), +, CR, LF, \ ✅ *Server-Validation via Zod; Prisma parameterized SQL verhindert Injection ohne Character-Rejection; DOMPurify sanitized Rich-Text.* - [x] For all input fields, forms, URLs and cookies in the application, only accept data from the end user or process that is expected. ✅ *Typed I/O via Zod auf tRPC + Cookies als HttpOnly (kein Client-Write).* - [x] Perform validation against session variables and parameters (e.g. URL variables, hidden fields etc.) ✅ *Session-State server-only (Auth.js), URL-Params via Next.js typed routes + Zod.* - [x] Ensure proper length limit on application parameters and URLs. Validate strings length, expected characters and pattern. Use regular expressions for validation as necessary. ✅ *Zod `.min()`/`.max()` auf relevanten Feldern (Compliance EAPPS 3.2.2.3.03).* - [x] Reject inputs with potentially malicious characters. Sanitize input to exclude context-changing symbols such as apostrophe, quotes, etc.; as well as script characters such as < > "" ' % ; ) ( & + JavaScript: img ✅ *DOMPurify auf Rich-Text; React escapt automatisch; Prisma parameterized SQL.* - [x] 6. Encode HTML input to prevent the client’s web browser from interpreting every users supplied input as executable code. Do not store sensitive data in cookies. ✅ *React auto-escape in JSX; Sensitive Daten nicht in Cookies (HttpOnly Session-only).* - [x] 7. Use libraries (e.g., anti-cross site scripting library such as .Net AntiXSS Library) to protect against security bugs during web application development. ✅ *DOMPurify auf User-Markdown/Rich-Text; React escapt alle String-Werte.* - [x] 8. Webdav should be left disabled, by default, if there is no business functionality that requires it. ✅ *nginx Reverse Proxy, keine WebDAV-Konfiguration aktiviert.* - [x] 9. Apply pre-requisites before using http methods DELETE, PUT, OPTIONS, PATCH HEAD. Refer to the Application Security Standard. Disable Trace method ✅ *tRPC nutzt nur GET/POST; andere Methoden nicht exposed (Compliance EAPPS 3.3.1.5.01).* - [x] 10. Use cookies securely: ✅ *Parent — siehe Sub-Items.* - [x] Set the 'Secure' and 'Httponly' attributes in the cookie. ✅ *`auth.config.ts` setzt `httpOnly: true` + `secure: production` + `sameSite: strict` auf allen Cookies.* - [x] Do not use the domain parameter unless you need to scope the cookie to other applications outside the current application. ✅ *Kein `domain` Parameter gesetzt (Default = current host only).* - [x] Set the proper scope of the ‘path’ attribute. ✅ *`path: '/'` — passend für Single-App-Deployment.* - [x] *For example, if the application resides at /myapp/, then set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. ✅ *Informational — nicht anwendbar bei Root-Deployment.* - [x] Establish Hard limits to the lifetime of authentication cookies. Do not set cookie expiration time unless a persistent cookie is required. Setting the expiration time changes a cookie from session to persistent and should be avoided where possible. In cases were a persistent cookie is a business requirement, limit the lifespan of the cookie to the shortest duration that meets the required business benefit. ✅ *`maxAge: 28800` (8h absolute), Session-basiert (kein persistent Cookie).* - [x] 11. Secure Cookie Content: ✅ *Parent — siehe Sub-Items.* - [x] The cookie must be input validated; ✅ *HttpOnly verhindert Client-Write; Server-Side liest nur getypte JWT-Claims.* - [x] If the cookie must not be modified by the user then it must be made tamper resistant with an HMAC or similar mechanism to protect integrity of cookie content. ✅ *Auth.js JWT-Signature (HMAC-SHA256 mit `AUTH_SECRET`); Mismatch → Session ungültig.* - [ ] If the user must not see the data in the cookie then it must also be encrypted. 🟡 *Session-Cookie ist signed (JWT), nicht encrypted. HttpOnly verhindert Einsicht via JS. **Follow-up:** Auth.js Encrypted-JWE evaluieren, falls sensitive Claims hinzukommen.* - [x] 12. Do not use sensitive parameters in the URL such as user id, sessionid and other sensitive parameters. ✅ *Keine User-IDs/Session-IDs in URLs; tRPC nutzt POST-Body + Cookie-Session.* - [x] 13. For Silverlight or Flash components, specify trusted domains in the client access policy or crossdomain policy configuration file. Do not leave domain = *. ⚪ *Kein Silverlight / Flash im Einsatz.* - [x] 14. Pages containing static sensitive data must not be cached. ✅ *`Cache-Control: no-store` global + auf Auth-Seiten (Compliance EAPPS 3.3.1.7.01).* - [x] 15. Avoid using URL redirects and forwards. If this cannot be avoided, verify that the parameter(s) are validated to contain only an allowed destination. ✅ *Auth.js `callbackUrl` wird gegen konfigurierte Base-URL validiert; keine Open-Redirects.* - [x] 16. Use HTTP POST-requests instead of HTTP GET-requests since all parameters will be found in the URL for a GET-request. In general, avoid transmitting passwords in URL. Use secure mechanisms instead, such as digital certificates for example for sending passwords. ✅ *Login und Mutations über POST (tRPC + Auth.js); keine Credentials in Query-Strings.* - [ ] 17. Create an inventory of all input fields, including Get parameters/hidden fields, and have these included in test scripts for input validation tests. 🟡 *Zod-Schemas sind im Code (einheitliche Quelle), aber **kein aggregiertes Test-Input-Inventory-Dokument**. Follow-up: Skript, das alle Zod-Schemas extrahiert und als Security-Test-Matrix ausgibt.* - [ ] 18. Conduct a critical evaluation to the level of scrutiny over approval process of when/how applications are opened to the internet and confirm that the following are in place: 🟡 *Parent — siehe Sub-Items zu Change-Control-Prozess.* - [ ] A structured change control review procedure to define two layers of review in advance of ports being opened to the internet. 🟡 *PR-Review + CI-Checks vorhanden (1 Layer). **TODO:** 2. Review-Layer für sicherheitskritische Änderungen (z. B. Auth, RBAC) dokumentieren.* - [ ] Review procedure is documented in this control and communicated. 🟡 *`docs/sdlc.md` dokumentiert PR-Prozess. **TODO:** Explizite Security-Change-Review-Sektion ergänzen.* - [ ] A ""final approver"" is identified. 🟡 *Repo-Owner ist de-facto Final-Approver (CODEOWNERS). **TODO:** Formal dokumentieren.* - [ ] Changes and connections must be approved by qualified security teams. 🟡 *Kleines Team ohne dediziertes Security-Team. **TODO:** Bei Security-relevanten PRs externen Review einplanen (z. B. Accenture Security-Kontakt).*
Hartmut added the cdpsecurity labels 2026-04-16 08:16:52 +02:00
Hartmut commented 2026-04-16 08:32:38 +02:00
Author
Owner
Copy Link
Copy Source

CapaKraken Action Plan — 35948520 Web Application Security

Scope: Kompletter ADM/CDP-Katalog für Web-Apps (36 Sub-Validation-Fragen siehe Checkbox-Liste unten).

Aktueller Stand (Auszug aus docs/acn-security-compliance-status.md, 3.3.1 Web Standards — 20+ Controls OK):

  • 3.3.1.1.01 Auth Standard, 3.3.1.2.01 XSS/Injection, 3.3.1.3 Headers, 3.3.1.4.01 Hardening, 3.3.1.5.01 Methods, 3.3.1.6.01 Cookies, 3.3.1.7.01 Caching, 3.3.1.8.01 Sensitive Info, 3.3.1.9.01 CSRF, 3.3.1.10.01 Errors, 3.3.1.12 API

Mapping der 36 Sub-Validation-Fragen auf vorhandene Nachweise:

  • Segmentation (Q1) — nginx + Docker-internal Networks
  • ADFS/SAML (Q2) — N/A — interne App ohne Federation
  • Input Validation (Q5–Q12) — Zod + DOMPurify (3.2.2.3.01/05 OK)
  • Cookie-Security (Q10) — HttpOnly/Secure/SameSite (3.3.1.6.01 OK)
  • URL-Params sensitiv (Q12) — tRPC nur POST, keine ID in URL (3.3.1.5.01 OK)
  • Silverlight/Flash (Q13) — N/A — keine Plugins
  • HTTPS POST statt GET (Q16) — tRPC nutzt POST (3.3.1.5.01 OK)
  • Input-Inventar (Q17) — jede Procedure hat Zod-Schema
  • Port-Changes Approval (Q18) — manuell über Ops + PR auf docker-compose.prod.yml (3.2.4.01 OK)

Todos:

  • Checkboxen oben pro Q1–18 einzeln markieren (compliant / not applicable / exception)
  • Gaps (falls vorhanden) als Unter-Issues verlinken
  • Evidence-Paket zusammenstellen in samples/CDP/attestations/webapp.pdf
### CapaKraken Action Plan — 35948520 Web Application Security **Scope:** Kompletter ADM/CDP-Katalog für Web-Apps (36 Sub-Validation-Fragen siehe Checkbox-Liste unten). **Aktueller Stand (Auszug aus `docs/acn-security-compliance-status.md`, 3.3.1 Web Standards — 20+ Controls **OK**):** - 3.3.1.1.01 Auth Standard, 3.3.1.2.01 XSS/Injection, 3.3.1.3 Headers, 3.3.1.4.01 Hardening, 3.3.1.5.01 Methods, 3.3.1.6.01 Cookies, 3.3.1.7.01 Caching, 3.3.1.8.01 Sensitive Info, 3.3.1.9.01 CSRF, 3.3.1.10.01 Errors, 3.3.1.12 API **Mapping der 36 Sub-Validation-Fragen auf vorhandene Nachweise:** - Segmentation (Q1) — nginx + Docker-internal Networks - ADFS/SAML (Q2) — **N/A** — interne App ohne Federation - Input Validation (Q5–Q12) — Zod + DOMPurify (3.2.2.3.01/05 OK) - Cookie-Security (Q10) — HttpOnly/Secure/SameSite (3.3.1.6.01 OK) - URL-Params sensitiv (Q12) — tRPC nur POST, keine ID in URL (3.3.1.5.01 OK) - Silverlight/Flash (Q13) — **N/A** — keine Plugins - HTTPS POST statt GET (Q16) — tRPC nutzt POST (3.3.1.5.01 OK) - Input-Inventar (Q17) — jede Procedure hat Zod-Schema - Port-Changes Approval (Q18) — manuell über Ops + PR auf `docker-compose.prod.yml` (3.2.4.01 OK) **Todos:** - [ ] Checkboxen oben pro Q1–18 einzeln markieren (compliant / not applicable / exception) - [ ] Gaps (falls vorhanden) als Unter-Issues verlinken - [ ] Evidence-Paket zusammenstellen in `samples/CDP/attestations/webapp.pdf`
Hartmut commented 2026-04-16 10:02:29 +02:00
Author
Owner
Copy Link
Copy Source

CapaKraken Compliance-Status

EAPPS-Mapping: 3.3.1.x (Web Application Standard)
Status: 🟡 PARTIAL / TODO — konkrete Schritte unten

Zusammenfassung

Web-App-Sicherheit ist überwiegend umgesetzt. Die 36 Sub-Validation-Questions in diesem Ticket + 5 Detail-Checklisten decken den vollen Scope ab.

Aktuelle Evidenz

Offene Aufgaben

  • 36 Sub-Validation-Questions (im Ticket-Body) einzeln beantworten/markieren.
  • Detail-Checkliste #31 (General) + #33 (HTML5) + #35 (ReactJs) + #34 (Node.js) + #32 (Cloud) abarbeiten.

Ticket bleibt offen bis alle Aufgaben abgehakt sind.

## CapaKraken Compliance-Status **EAPPS-Mapping:** `3.3.1.x (Web Application Standard)` **Status:** 🟡 **PARTIAL / TODO** — konkrete Schritte unten ### Zusammenfassung Web-App-Sicherheit ist überwiegend umgesetzt. Die 36 Sub-Validation-Questions in diesem Ticket + 5 Detail-Checklisten decken den vollen Scope ab. ### Aktuelle Evidenz - Security Headers (HSTS, CSP, X-Frame-Options, Referrer-Policy) — [`apps/web/next.config.ts`](../blob/main/apps/web/next.config.ts) - Rate-Limiting — [`packages/api/src/middleware/rate-limit.ts`](../blob/main/packages/api/src/middleware/rate-limit.ts) - Compliance-Doc: EAPPS 3.3.1.1–3.3.1.12 überwiegend **OK** ### Offene Aufgaben - [ ] 36 Sub-Validation-Questions (im Ticket-Body) einzeln beantworten/markieren. - [ ] Detail-Checkliste #31 (General) + #33 (HTML5) + #35 (ReactJs) + #34 (Node.js) + #32 (Cloud) abarbeiten. --- *Ticket bleibt offen bis alle Aufgaben abgehakt sind.*
Hartmut commented 2026-04-16 10:16:34 +02:00
Author
Owner
Copy Link
Copy Source

Review-Ergebnis: 36 Sub-Validation-Questions

Status Anzahl
✅ OK 25
🟡 PARTIAL 7
🔴 GAP 0
⚪ N/A 4
Total 36

Detail-Evidenz inline in jedem Check-Item vermerkt.

🟡 Partial-Items (Follow-ups)

  1. Cookie-Encryption (Q11.3) — aktuell signed JWT. Bei sensitiver Claim-Erweiterung auf Encrypted-JWE (Auth.js option) evaluieren.
  2. Input-Inventory-Dokument (Q17) — Zod-Schemas aggregieren als Test-Matrix.
  3. Security-Change-Review-Prozess (Q18.x — 4 Sub-Items) — 2-Layer-Review + dokumentierten Final-Approver für sicherheitskritische PRs formalisieren.

⚪ N/A-Items

Q2 (ADFS/SAML), Q3 (WSDL), Q4 (AD account), Q13 (Silverlight/Flash) — Technologien werden in CapaKraken nicht verwendet.

Verwandte Tickets

  • Detail-Checkliste #31 (35 General Web-App Checks) — 4 Gaps + 4 Partials offen
  • Detail-Checkliste #33 HTML5, #34 Node.js, #35 ReactJs → alle geschlossen ✅
  • Detail-Checkliste #32 Cloud → geschlossen als N/A

Empfehlung

Die 4 Partials in Q18.x hängen am Change-Management-Prozess — das läuft als Doku-TODO in Parent-Ticket #1 (Epic). Die 2 anderen Partials (Q11.3 Cookie-JWE, Q17 Input-Inventory) sind kleine Follow-ups.

Keine echten Gaps in den 36 Fragen. Ticket kann nach Abarbeitung von #31 (enthält die 4 Gaps für Password-Handling) geschlossen werden.

## Review-Ergebnis: 36 Sub-Validation-Questions | Status | Anzahl | |--------|--------| | ✅ OK | 25 | | 🟡 PARTIAL | 7 | | 🔴 GAP | 0 | | ⚪ N/A | 4 | | **Total** | **36** | Detail-Evidenz inline in jedem Check-Item vermerkt. ### 🟡 Partial-Items (Follow-ups) 1. **Cookie-Encryption** (Q11.3) — aktuell signed JWT. Bei sensitiver Claim-Erweiterung auf Encrypted-JWE (Auth.js option) evaluieren. 2. **Input-Inventory-Dokument** (Q17) — Zod-Schemas aggregieren als Test-Matrix. 3. **Security-Change-Review-Prozess** (Q18.x — 4 Sub-Items) — 2-Layer-Review + dokumentierten Final-Approver für sicherheitskritische PRs formalisieren. ### ⚪ N/A-Items Q2 (ADFS/SAML), Q3 (WSDL), Q4 (AD account), Q13 (Silverlight/Flash) — Technologien werden in CapaKraken nicht verwendet. ### Verwandte Tickets - Detail-Checkliste #31 (35 General Web-App Checks) — 4 Gaps + 4 Partials offen - Detail-Checkliste #33 HTML5, #34 Node.js, #35 ReactJs → **alle geschlossen** ✅ - Detail-Checkliste #32 Cloud → geschlossen als N/A ### Empfehlung Die 4 Partials in Q18.x hängen am Change-Management-Prozess — das läuft als Doku-TODO in Parent-Ticket #1 (Epic). Die 2 anderen Partials (Q11.3 Cookie-JWE, Q17 Input-Inventory) sind kleine Follow-ups. Keine echten Gaps in den 36 Fragen. Ticket kann nach Abarbeitung von #31 (enthält die 4 Gaps für Password-Handling) geschlossen werden.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
cdp
CDP (Client Data Protection) compliance
 epic
Parent/umbrella ticket
 not-applicable
Control does not apply to CapaKraken scope
 security
Security / compliance work
No Label cdp security
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Hartmut
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Hartmut/CapaKraken#25
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?