Last updated: 10 September 2026
Security approach
ElectroDesigner uses layered controls appropriate to a small engineering web application: HTTPS, server-side sessions for licensed access, HttpOnly and SameSite session-cookie settings, CSRF checks on protected FaultChain requests, input-size controls, restricted private/API paths, anti-framing and content-type response headers, and conservative handling of external licence-verification requests.
Build 14 also adds site-wide response-header hardening where supported by the Apache/Hostinger environment, disables directory listing, publishes a crawler policy in /robots.txt and provides a standard /.well-known/security.txt contact file.
Responsible disclosure
If you believe you have found a security vulnerability affecting ElectroDesigner.com or FaultChain, send a concise report to info@electrodesigner.com with the subject “Security report - ElectroDesigner”. Include the affected URL, the issue, reproducible steps and the security impact. Do not include real licence keys, passwords, payment-card data or unrelated personal data.
Safe testing rules
Good-faith testing must avoid destructive actions, denial-of-service or traffic flooding, automated high-rate scanning, accessing or modifying another user's data or licence, social engineering, physical attacks, persistence, malware deployment or public disclosure before a reasonable remediation opportunity.
Use test data and your own browser/session. Stop testing if you encounter information that appears to belong to another person and report the issue without further access.
Out of scope
Purely informational findings without a realistic security impact, missing headers that are already intentionally documented, clickjacking claims on pages already protected by framing controls, self-XSS requiring a user to paste code into developer tools, and issues solely in third-party services are normally out of scope unless they create a concrete risk to ElectroDesigner users.
No bug bounty promise
ElectroDesigner does not currently operate a paid vulnerability-reward programme. Responsible reports are nevertheless welcomed and will be reviewed according to severity and reproducibility.
Security limitations
No website can guarantee absolute security. Security controls must also be supported by the active hosting stack and can change as the application evolves. Sensitive engineering secrets should not be stored in project names or notes unless a future product feature explicitly documents support for confidential project storage.