DDactic
Find What Defenses Miss
Reporting Security Issues
If you find a real, exploitable issue on a DDactic-operated surface (excluding the deliberately vulnerable demo target at challenge.ddactic.net), please report it privately first.
- Email: [email protected]
- Acknowledgment: within 48 hours
- Triage update: within 7 days
- Recognition: opt-in credit on this page
- For real findings on production surfaces: Founding Design Partner pricing for life (90% off the engagement, no time limit). One per researcher.
Please do not test customer dashboards or production APIs without coordinating first. challenge.ddactic.net is fair game and intentionally vulnerable.
Machine-readable disclosure policy: /.well-known/security.txt
What's Protected Today
Customer dashboards (app.ddactic.net, ddactic.net)
- Cloudflare in front, full proxy, no direct origin exposure on dashboard paths
- Sessions:
HttpOnly; Secure; SameSite=Lax cookies
- Magic-link guest endpoints (
/api/auth/magic-guest): per-IP rate limit, 16+ char crypto-random tokens, format-validated before KV lookup, separate buckets for valid vs invalid attempts
- Session bound to user's
organizationId at issuance; downstream API calls scope by session
- Backend API (Dedibox
api.ddactic.net): UFW restricts port 8080 to Cloudflare IPs only
Public demo target (challenge.ddactic.net)
- Intentionally vulnerable at the application layer (open
/admin, fake admin keys at /api/v1/users, GraphQL introspection, CORS *) — this is the scanner's target, by design
- Visible warning banner on every page; titles tagged
[DEMO TARGET]
- Cloudflare-fronted with origin firewall: iptables drops anything not in CF, CloudFront, Fastly, or Azure CDN ranges; Docker forward chain also gated
- Origin IP rotation completed 2026-05-01 after CT log audit
Backbone infrastructure
- SSH access only via Cloudflare Tunnel (
ssh.ddactic.net), key-based, password auth disabled
- Dedibox port 22 closed at the firewall — direct SSH not reachable
- Secrets in AWS SSM Parameter Store as
SecureString; tokens.env fallback for local dev
- CT log audit done 2026-05-01: no leaked origin IPs in current DNS records
On the Roadmap
The honest list. Things we know are table stakes for enterprise procurement and are sequenced for the next few releases.
Authentication hardening (next)
- MFA required at paid signup (TOTP at minimum, WebAuthn / passkey preferred)
- Email verification before account activation
- Session: 30 min idle timeout, 4 hr absolute, rotate token on login
Tenant audit log (next)
- Per-organization timeline visible inside the customer's own dashboard
- Login events with IP + user agent + geographic hint
- Sensitive actions: invite, role change, scan submission, data export
SSO (after first procurement asks)
- Google Workspace, Microsoft Entra ID, Okta — SAML and OIDC
- SCIM provisioning for enterprise tier
Compliance (longer term, demand-driven)
- SOC 2 Type II (estimated 12-18 months once we have customer #5)
- ISO 27001 (Israeli market expects it; sequenced after SOC 2)
What We Don't Do
- We don't sell or share customer data with third parties for marketing
- We don't run active scans against domains outside what the customer has authorized
- We don't keep raw scan output longer than the customer's retention setting (default: 90 days for free tier, configurable for paid)
- We don't ship features faster than we can secure them; this page is updated whenever an item moves between roadmap and production
Acknowledgments
Thanks to security researchers and CISOs who have reported issues responsibly. Listed with their permission only.
No public disclosures yet — this section will populate as researchers opt in.