Security Practices

• •Least Privilege: Systems and personnel are granted only the minimum access necessary to perform their function.
• •Defense in Depth: Multiple layers of security controls protect against single points of failure.
• •Data Minimization: We collect and retain only the personal information necessary to provide the Service.
• •Continuous Monitoring: Automated systems monitor for anomalous activity and security events.
• •Secure by Design: Security considerations are integrated into the development process, not applied after the fact.

• •Encryption in Transit: All data transmitted between your browser and the Service is encrypted using TLS (HTTPS).
• •Access Controls: Access to user data is restricted to authorized systems and personnel. Administrative access requires verified authentication.
• •Data Minimization: We do not store sensitive personal information (such as addresses, dates of birth, or phone numbers) beyond what is required for the Service's core function. When personal information is needed for a specific action (such as an appeal letter), it is collected at the point of use and is not retained after the action is completed.

• •Hosting: The Service is hosted on infrastructure with industry-standard physical and network security controls.
• •Environment Isolation: Production systems are separated from development and testing environments. Sensitive credentials are scoped to production only.
• •Dependency Management: Third-party software dependencies are regularly audited for known vulnerabilities.

• •Authentication: User authentication is handled through a trusted third-party identity provider (Google). No passwords are stored by SaxaLit.
• •Session Management: User sessions expire after a defined period. Session tokens are stored in secure, httpOnly cookies.
• •Input Validation: User-supplied input is validated and sanitized before processing.
• •Bot Protection: Public-facing forms are protected by automated bot detection to prevent abuse.
• •Rate Limiting: Public endpoints that trigger actions (email sending, form submissions) are rate-limited to prevent abuse.
• •Security Headers: The Service implements standard security headers including Content Security Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy.

• •Anomaly Detection: Security-relevant events (failed authentication attempts, rate limit violations, unusual account activity) are tracked with automated counters and reported daily.
• •Threshold Alerting: When security event counters exceed defined thresholds, alerts are generated and reviewed.
• •Automated Scanning: The Service undergoes weekly automated security scanning, including vulnerability assessment and dependency auditing.

In the event of a security incident that affects user data:

• •We will investigate and contain the incident as quickly as possible.
• •We will notify affected users and applicable regulatory authorities within the timeframes required by law.
• •We will provide a clear description of what occurred, what data was affected, and what steps we are taking in response.

To report a security concern or vulnerability, contact us.

• •Keep your Google account credentials secure — SaxaLit's security depends on the security of your Google account.
• •Do not share your account with others.
• •Report any suspicious activity on your account through our contact page immediately.

The Service integrates with third-party providers for authentication, payment processing, email delivery, data storage, and hosting. Each provider maintains its own security practices. While we select providers with strong security track records, we cannot guarantee the security of third-party systems.

No system can be completely secure. While we implement reasonable technical and organizational measures to protect your information, we cannot guarantee that our security measures will prevent every potential breach. Our Terms of Service describe the limitations on our liability.

For security-related questions or to report a vulnerability: