address copilot review followups (#96)

docs/AUDIT_SUMMARY.md

@@ -135,7 +135,7 @@ DMARQ has **excellent Python code quality** and **strong security infrastructure
    - Some API tests failing
 
 2. **CSP TODOs**
-   - 3 documented TODOs to remove unsafe-inline/unsafe-eval
+   - Documented TODOs to remove remaining unsafe-inline allowances
    - Currently weakens security
 
 3. **Accessibility Gaps**

docs/CODE_QUALITY_AUDIT_2026-02.md

@@ -94,7 +94,7 @@ This comprehensive audit evaluated the DMARQ codebase across multiple dimensions
 #### 📝 Recommendations
 
 1. **Priority: Low** - Consider extracting helper functions from complex methods if readability suffers
-2. **Priority: Medium** - Address CSP TODOs (remove unsafe-inline/unsafe-eval)
+2. **Priority: Medium** - Address CSP TODOs (remove remaining unsafe-inline allowances)
 3. **Priority: Low** - Migrate from Pydantic v1 validators to v2 field_validator
 
 ---
@@ -272,14 +272,15 @@ document.getElementById('openModalBtn').addEventListener('click', () => {
    - Documented with clear warnings in code
 
 2. **CSP Unsafe Directives**
-   - Uses 'unsafe-inline' and 'unsafe-eval'
+   - Uses 'unsafe-inline'
+   - 'unsafe-eval' has been removed from the current policy
    - Tracked with TODOs in code
    - Documented in SECURITY.md
 
 #### 📝 Recommendations
 
 **Priority: MEDIUM**
-1. Remove CSP unsafe-inline/unsafe-eval directives
+1. Remove remaining CSP unsafe-inline directives
 2. Implement nonce-based CSP for scripts/styles
 3. Move API keys to database/Redis for production
 
@@ -425,7 +426,7 @@ document.getElementById('openModalBtn').addEventListener('click', () => {
 ## Summary of TODOs Found in Codebase
 
 1. **middleware/security.py (3 instances):**
-   - Line 55: Remove 'unsafe-inline' and 'unsafe-eval' and use nonces/hashes instead
+   - Line 55: Remove remaining 'unsafe-inline' allowances and use nonces/hashes instead
    - Line 61: Use nonces for script-src
    - Line 62: Use nonces for style-src
 

docs/FOLLOW_UP_SUMMARY.md

@@ -45,11 +45,11 @@ Content Security Policy hardening has been documented with detailed plans:
    - Added CDN sources to CSP whitelist
 
 2. **Analysis** - ✅ COMPLETE
-   - Verified no eval() usage (unsafe-eval can be removed)
+   - Verified no eval() usage and removed `unsafe-eval` from `script-src`
    - Identified all inline script locations
    - Documented inline style usage
 
-3. **Implementation** - ⚠️ FUTURE WORK
+3. **Remaining Implementation** - ⚠️ FUTURE WORK
    - Requires moving inline scripts to external files
    - Or implementing CSP nonces (more complex)
    - Priority: HIGH
@@ -58,7 +58,8 @@ Content Security Policy hardening has been documented with detailed plans:
 **Current CSP Status**:
 - ✅ Documented comprehensive plan
 - ✅ Added TODO comments with specific steps
-- ⚠️ Still includes unsafe-inline/unsafe-eval
+- ✅ Removed `unsafe-eval` from `script-src`
+- ⚠️ Still includes `unsafe-inline`
 - ⚠️ Requires template refactoring to fix
 
 ### 📊 MEDIUM - Test Suite Remediation (ANALYZED, PARTIAL)
@@ -143,7 +144,7 @@ Comprehensive audit process has been documented:
 2. ✅ Audit process established for ongoing monitoring
 
 ### Remaining Risks
-1. ⚠️ CSP still allows unsafe-inline/unsafe-eval (documented, planned)
+1. ⚠️ CSP still allows `unsafe-inline` (documented, planned)
 2. ⚠️ Some test failures indicate potential integration issues (non-security)
 
 ## Metrics
@@ -177,7 +178,8 @@ Comprehensive audit process has been documented:
 
 ### Short-term (Next Sprint)
 - [ ] Move inline scripts to external files
-- [ ] Remove 'unsafe-eval' from CSP
+- [x] Remove 'unsafe-eval' from CSP
+- [ ] Remove 'unsafe-inline' from CSP
 - [ ] Test with stricter CSP
 - [ ] Fix test suite database schema issues
 - [ ] Resolve failing API tests

docs/XSS_FIXES.md

@@ -239,7 +239,7 @@ After fixing the XSS issues, update your CSP header in `backend/app/middleware/s
 
 ### Current (Insecure)
 ```python
-"script-src 'self' 'unsafe-inline' 'unsafe-eval'",
+"script-src 'self' 'unsafe-inline' https://cdn.tailwindcss.com https://cdn.jsdelivr.net",
 "style-src 'self' 'unsafe-inline' https://fonts.googleapis.com",
 ```
 
@@ -255,6 +255,7 @@ After fixing the XSS issues, update your CSP header in `backend/app/middleware/s
 - [ ] All user input uses `textContent` not `innerHTML`
 - [ ] No credentials stored in localStorage
 - [ ] Inline styles replaced with CSS classes
+- [x] CSP headers updated to remove 'unsafe-eval'
 - [ ] CSP headers updated to remove 'unsafe-inline'
 - [ ] Manual XSS testing completed
 - [ ] Automated tests added

docs/XSS_FIXES_VERIFICATION.md

@@ -195,7 +195,8 @@ No review comments found.
 ## Remaining Work
 
 ### CSP Hardening (Future Work)
-The Content Security Policy still includes `unsafe-inline` and `unsafe-eval` directives. To remove these:
+The Content Security Policy no longer includes `unsafe-eval`, but it still
+includes `unsafe-inline`. To remove the remaining unsafe inline allowances:
 
 1. **For script-src 'unsafe-inline'**:
    - Move inline `<script>` blocks from templates to external .js files
@@ -203,9 +204,8 @@ The Content Security Policy still includes `unsafe-inline` and `unsafe-eval` dir
    - Files with inline scripts: index.html, domains.html, reports.html, settings.html, upload.html, domain_details.html, base.html
 
 2. **For script-src 'unsafe-eval'**:
-   - Current scan shows no eval() usage
-   - Can be removed after testing
-   - Verify no third-party libraries require eval
+   - Removed from the current CSP after verifying no eval() usage
+   - Continue to verify new third-party libraries do not require eval
 
 3. **For style-src 'unsafe-inline'**:
    - Move inline styles to CSS files
@@ -244,7 +244,8 @@ The setup wizard currently collects Cloudflare credentials but doesn't persist t
 
 2. **Short-term** (Next Sprint):
    - Move inline scripts to external files
-   - Remove 'unsafe-eval' from CSP
+   - Keep `unsafe-eval` out of CSP
+   - Remove remaining `unsafe-inline` directives
    - Test application functionality with stricter CSP
 
 3. **Medium-term** (Next Quarter):

docs/deployment/configuration.md

@@ -42,7 +42,7 @@ DMARQ can be configured through:
 | `LOGTO_APP_ID` | Client ID of the Logto application | - | `your-app-id` |
 | `LOGTO_APP_SECRET` | Client Secret of the Logto application | - | `your-app-secret` |
 | `LOGTO_REDIRECT_URI` | Override the OAuth callback URL | Auto-detected | `https://dmarq.example.com/api/v1/auth/callback` |
-| `LOGTO_SKIP_SSL_VERIFY` | Disable SSL certificate verification for connections to the Logto endpoint. **Only use this when your Logto instance uses a self-signed certificate that you control. Never enable in production environments.** | `true` | `true`, `false` |
+| `LOGTO_SKIP_SSL_VERIFY` | Disable SSL certificate verification for connections to the Logto endpoint. **Only use this when your Logto instance uses a self-signed certificate that you control. Never enable in production environments.** | `false` | `true`, `false` |
 
 ### IMAP Settings
 
@@ -187,4 +187,4 @@ DMARQ validates your configuration on startup. If there are issues, they will be
 - IMAP credentials (if IMAP is enabled)
 - SMTP credentials (if alerting is enabled)
 
-Check the application logs if you encounter startup issues related to configuration.
+Check the application logs if you encounter startup issues related to configuration.