GreenRobot Blog

A B Rating From CodeFrog

While building CodeFrog’s landing page, we integrated Mailchimp for newsletter signups. However, our security scans revealed a critical issue that prevents us from achieving an A rating: Mailchimp’s validation script violates Content Security Policy (CSP) requirements.

The Security Violation

Mailchimp’s mc-validate.js script injects inline styles dynamically, which requires the 'unsafe-inline' directive in our CSP style-src policy. This is a security anti-pattern because:

1. CSP Bypass Risk: 'unsafe-inline' allows any inline styles, defeating the purpose of CSP protection against XSS attacks
2. Nonce Incompatibility: Even when using CSP nonces for our own styles, Mailchimp’s dynamically injected styles can’t use nonces, forcing us to allow all inline styles
3. Security Rating Impact: Security scanners (like our own Mega Report) flag this as a MEDIUM severity issue, preventing an A rating

The Error

When we removed 'unsafe-inline' to improve security, the browser console shows:

Applying inline style violates the following Content Security Policy directive: 
`style-src 'self' 'nonce-...'`. The action has been blocked.

This error originates from mc-validate.js:164, confirming that Mailchimp’s script requires unsafe inline styles to function.

Why This Matters

Content Security Policy is a critical security feature that helps prevent:

• Cross-Site Scripting (XSS) attacks
• Data injection attacks
• Code injection vulnerabilities

By requiring 'unsafe-inline', Mailchimp forces us to weaken our security posture, which is unacceptable for a security-focused tool like CodeFrog.

What We Need

We’re looking for a newsletter service that:

✅ Free tier (or very affordable) for up to 500 subscribers
✅ CSP-compliant – doesn’t require 'unsafe-inline'
✅ Secure by default – supports nonces or external stylesheets
✅ Easy integration – simple embed or API
✅ Reliable – good deliverability and uptime

Call for Recommendations

We’re reaching out to the developer community for recommendations. If you know of a newsletter service that:

• Respects modern web security standards
• Works with strict CSP policies
• Offers a free tier for small lists
• Provides good deliverability

Please share your suggestions! We’re particularly interested in:

• Self-hosted solutions (if they’re easy to set up)
• Modern alternatives that prioritize security
• Services that use external stylesheets or support CSP nonces
• Any workarounds for making Mailchimp CSP-compliant (if they exist)

The Solution: CSP Hash Instead of Unsafe-Inline

Good news! We found a solution that doesn’t require 'unsafe-inline'. When we removed 'unsafe-inline' from our CSP, the browser console error message actually provided the answer:

Applying inline style violates the following Content Security Policy directive: 
'style-src 'self' 'nonce-...''. Either the 'unsafe-inline' keyword, a hash 
('sha256-iIHQ0a6ntSSQhfMwBwjvXvp+zrKJldURld+iiblnEKo='), or a nonce 
('nonce-...') is required to enable inline execution.

The browser helpfully suggested using a hash for the specific inline style instead of allowing all inline styles. This is a much better security approach!

What We Changed

Instead of using 'unsafe-inline' in our CSP style-src directive, we now use:

style-src 'self' 'nonce-{style_nonce}' 'sha256-iIHQ0a6ntSSQhfMwBwjvXvp+zrKJldURld+iiblnEKo='

This hash is specific to the inline style that Mailchimp’s mc-validate.js script injects. By using the hash, we:

✅ Allow only that specific style – not arbitrary inline styles
✅ Maintain strict CSP – no 'unsafe-inline' directive
✅ Pass security scans – scanners don’t flag specific hashes
✅ Keep Mailchimp working – the validation script functions correctly

Why This Is Better

Using a hash is more secure than 'unsafe-inline' because:

• It’s whitelist-based: Only the exact style with that hash is allowed
• It’s CSP-compliant: Security scanners accept hashes as a valid, secure approach
• It’s maintainable: If Mailchimp changes their script, we’ll get a new error with a new hash to add

Remaining Issue

While we’ve solved the CSP style-src issue, there’s still one security concern:

⚠️ SRI (Subresource Integrity) Missing: Mailchimp’s script is loaded from their S3 bucket without an integrity attribute. This means we can’t verify the script hasn’t been tampered with. However, this is a known limitation because:

• Mailchimp’s script is dynamically generated and changes frequently
• Their S3 bucket doesn’t send CORS headers, which would be required for SRI
• Adding crossorigin="anonymous" would break script loading due to CORS issues

This is a MEDIUM severity issue that prevents a perfect A+ rating, but it’s an acceptable trade-off given the constraints.

Conclusion

As a security-focused developer tool, CodeFrog needs to maintain the highest security standards. We’ve successfully resolved the CSP 'unsafe-inline' issue by using a hash-based approach, which is more secure and CSP-compliant.

The remaining SRI issue is a known limitation with third-party scripts that don’t support CORS, and we’ve documented it appropriately. We’re now much closer to that A security rating!

Update: We solved the CSP issue using a hash-based approach! The browser’s error message provided the exact hash we needed. Mailchimp now works with strict CSP without requiring 'unsafe-inline'.

Introduction

Accessibility is not a feature—it’s a fundamental requirement for modern web and mobile applications. Over 1 billion people worldwide live with disabilities, and many rely on assistive technologies to navigate digital products. Beyond the moral imperative, accessible applications reach broader audiences, improve SEO rankings, and help organizations comply with legal standards like WCAG 2.1 and the Americans with Disabilities Act (ADA).

However, accessibility testing remains challenging for many development teams. Manual testing is time-consuming and error-prone, while developers often lack the expertise to identify subtle accessibility violations. This is where automated testing tools become invaluable.

The Challenge: Common Accessibility Issues

Developers frequently encounter accessibility barriers that go unnoticed during standard testing:

• Missing alt text on images, leaving screen reader users without context
• Insufficient color contrast making content unreadable for users with low vision
• Unlabeled form fields confusing users relying on screen readers
• Broken heading hierarchy disrupting document structure and navigation
• Missing ARIA attributes preventing assistive technologies from understanding dynamic content
• Keyboard navigation failures excluding users who cannot use a mouse
• Missing focus indicators making it impossible to track keyboard position

These issues compound, creating frustrating experiences for users with disabilities while exposing organizations to legal liability.

CodeFrog’s Solution: Automated Accessibility Testing

CodeFrog integrates axe-core, the industry-leading automated accessibility testing engine, directly into your development workflow. This powerful integration enables developers to catch accessibility violations early—during development, not after deployment.

With CodeFrog’s Web Testing feature, you can:

1. Test multiple sources: Select a local HTML file, enter a URL (localhost, staging, or production), or test a remote server
2. Test entire sites through sitemap testing: Provide a sitemap URL to automatically test all pages across your entire website, ensuring comprehensive accessibility coverage
3. Run automated accessibility scans powered by axe-core
4. View detailed violation reports with severity levels and remediation guidance
5. Iterate quickly with instant feedback on accessibility improvements

Whether you’re testing a development server running on localhost:3000, a staging environment, a production URL, or an entire site via sitemap, CodeFrog brings accessibility testing directly into your workflow.

What axe-core Detects

axe-core performs comprehensive automated testing across multiple accessibility standards:

Image and Media

• Missing or empty alt attributes on images
• Unlabeled buttons and icons
• Missing captions on video content

Color and Contrast

• Text with insufficient contrast ratios (WCAG AA/AAA standards)
• Color-only information without alternative indicators

Forms and Labels

• Form inputs without associated labels
• Missing or incorrect for attributes on labels
• Unlabeled fieldsets and legend elements

Document Structure

• Improper heading hierarchy (skipping levels like H1 → H3)
• Missing page landmarks (main, navigation, contentinfo)
• Duplicate IDs on page elements

ARIA and Semantics

• Invalid ARIA roles and attributes
• Missing required ARIA properties
• Misused semantic HTML elements

Keyboard Navigation

• Interactive elements not keyboard accessible
• Missing focus indicators
• Keyboard traps preventing escape

Benefits for Your Development Team

Shift-Left Testing: Catch accessibility issues before code review, reducing remediation costs and timeline pressure.

Developer Education: Detailed violation reports help your team understand why issues matter and how to fix them, building accessibility expertise across the organization.

Continuous Improvement: Integrate accessibility testing into your CI/CD pipeline to prevent regressions.

Compliance Confidence: Demonstrate accessibility commitment to stakeholders, customers, and regulators.

Inclusive Products: Build applications that work for everyone, expanding your user base and market reach.

Getting Started

CodeFrog makes accessibility testing accessible to developers of all experience levels. Whether you’re building a new feature or auditing an existing application, the Web Testing feature provides actionable insights to improve your digital products.

Start testing today and join the movement toward truly inclusive web development.

CodeFrog: Empowering developers to build accessible, inclusive applications.

The Problem

Implementing native drag-and-drop functionality in a Flutter macOS application that works seamlessly with scrolling and file selection proved to be one of the most challenging features we’ve built. The goal was simple: allow users to drag files into and out of CodeFrog, supporting both local and network (SSH) projects, while maintaining smooth scrolling and file selection.

Initial Attempt: super_drag_and_drop

We started with the super_drag_and_drop package, which provides cross-platform drag-and-drop support. While it worked for basic scenarios, we encountered several issues:

1. Unreliable drag-out for remote files – Files on network/SSH connections needed to be downloaded before dragging, and the async nature of this operation caused frequent failures
2. Gesture conflicts – The package’s gesture recognizers conflicted with Flutter’s built-in scrolling and selection mechanisms
3. Limited control – We needed more fine-grained control over the drag-and-drop behavior, especially for handling remote file downloads

After many hours of debugging and attempting workarounds (pre-downloading files, using virtual files, adjusting gesture recognizers, etc.), we decided to build a custom solution using native macOS APIs.

The Custom Solution: flutter_macos_drag

We built a custom Flutter plugin (flutter_macos_drag) that uses native macOS NSDraggingSource and NSDraggingDestination protocols directly. This gave us complete control over the drag-and-drop behavior.

Key Components

1. MacOSDraggable – A Flutter widget for dragging files out of the app
2. MacOSDroppable – A Flutter widget for accepting file drops from Finder
3. DraggableNSView – Native Swift view implementing NSDraggingSource and NSDraggingDestination

The Challenge: Scrolling vs Drag-and-Drop

The biggest challenge was making drag-and-drop work while preserving scrolling functionality. The native AppKitView needed to be in the widget hierarchy to receive drag events, but it was blocking pointer events needed for scrolling.

Failed Approaches:

• Using IgnorePointer – Blocked drag events
• Using AbsorbPointer – No effect
• Using Listener with HitTestBehavior – Still blocked events
• Reversing Stack order – Drag events didn’t reach the native view

The Solution: hitTest Override

The breakthrough came from understanding how macOS handles drag events vs pointer events:

1. Drag events work at the NSView level and query all registered views directly, completely bypassing Flutter’s pointer system and hit testing
2. Pointer events (scrolling, clicking) go through normal hit testing

By overriding hitTest in the native view to return nil for drop zones, we allow pointer events to pass through to Flutter widgets below, while drag events still work because they query registered views directly.

override func hitTest(_ point: NSPoint) -> NSView? {
    // For drop zones, return nil to let pointer events pass through to Flutter
    // Drag events don't use hitTest - they query all registered views directly
    if acceptDrops && filePath == nil {
        return nil
    }
    return super.hitTest(point)
}

Additionally, we made mouse event handlers return early for drop zones:

override func mouseDown(with event: NSEvent) {
    // For drop zones, don't handle mouse events - let them pass through for scrolling
    if acceptDrops && filePath == nil {
        return // Don't call super - allows events to pass through
    }
    // ... handle drag-out logic
}

Widget Structure

The final widget structure uses a Stack with the native view on top:

Stack(
  children: [
    // Native view on top - configured to not block pointer events
    Positioned.fill(
      child: Opacity(
        opacity: 0.01,
        child: AppKitView(...),
      ),
    ),
    // Flutter widgets below - receive pointer events for scrolling
    widget.child,
  ],
)

Features Achieved

✅ Drag files out – Works for both local and network files
✅ Drag files in – Accepts drops from Finder into any directory
✅ Scrolling – File tree pane scrolls smoothly
✅ File selection – Click to select files works normally
✅ Remote file handling – Downloads remote files on-demand during drag
✅ Root directory support – Can drop files at project root (empty path)

Key Technical Insights

1. macOS drag events bypass Flutter’s pointer system – They query all registered views directly, so IgnorePointer and similar widgets don’t affect them
2. hitTest controls pointer events, not drag events – Returning nil from hitTest allows pointer events to pass through while drag events still work
3. View registration is separate from hit testing – Views registered with registerForDraggedTypes receive drag events regardless of hitTest results
4. Mouse event handlers must return early – For drop zones, don’t call super in mouse event handlers to allow events to pass through

Lessons Learned

• Sometimes a custom native solution is necessary when cross-platform packages don’t meet specific requirements
• Understanding the underlying platform APIs (NSDraggingSource/NSDraggingDestination) is crucial
• The interaction between Flutter’s pointer system and native platform views requires careful consideration
• Persistence pays off – this took many hours but resulted in a robust, maintainable solution

This solution was developed over many hours of debugging and research. The key was understanding that macOS drag events operate at a different level than pointer events, allowing us to let pointer events pass through while still receiving drag events.