Skip to content

Security Policy

Last updated: 2026-05-21.

1. Scope

This policy explains how to report security issues affecting FreedivingHome (freedivinghome.com) and summarises the categories of security measures protecting the Service.

For personal-data processing details, see the Privacy Policy. For user obligations on account security, see the Terms of Service, Section 5.

This policy does not grant permission for testing outside the scope defined below.

2. Reporting a vulnerability

Contact: [email protected]

Please prefix the subject line with [SECURITY].

What to include

Please include:

  • a clear description of the issue and its potential impact;
  • the steps required to reproduce it, including any preconditions;
  • a minimal proof of concept, where appropriate;
  • the affected URL, endpoint, feature, or user flow;
  • whether any personal data, third-party data, or service disruption was encountered;
  • your contact details and, optionally, the name or handle you would like used for acknowledgment.

Do not include unnecessary personal data, secrets, credentials, database extracts, screenshots of other users' data, or exploit material beyond what is strictly needed to demonstrate the issue.

Sensitive reports

If your report contains sensitive details, say so in your first message and we will provide a secure communication method where available.

Do not publish exploit details, proof-of-concept code, or third-party data before coordinated disclosure has been completed.

Response targets

We aim to:

  • acknowledge new reports within 5 business days;
  • provide an initial assessment within 20 business days;
  • keep the reporter informed of material progress where practical.

These are response targets, not guaranteed service levels. Remediation timing depends on severity, exploitability, impact, available mitigations, and operational constraints.

Coordinated disclosure

We ask you to give us a reasonable opportunity to investigate and remediate before public disclosure.

Our default coordination window is 90 calendar days after we confirm that a report describes a valid vulnerability, unless:

  • we agree on a different timeline with you;
  • earlier disclosure is required to protect users or the public;
  • the issue is already being actively exploited or publicly disclosed;
  • legal or regulatory obligations require a different approach.

Where appropriate, we will coordinate disclosure language with you and credit you with your permission.

3. Safe harbour for good-faith research

We welcome good-faith security research.

If you comply with this policy and keep your testing within the scope defined in Section 4, we will treat your testing as authorised for the purposes of our systems and will not initiate civil claims or criminal complaints against you for that testing.

This commitment is intended to reduce legal uncertainty for good-faith research, including under Italian law on unauthorised access to IT systems. It does not bind third parties and does not prevent action where required by law.

To benefit from this commitment, you must:

  • act in good faith and avoid harm to the Service, its users, and third parties;
  • test only the systems and features in scope;
  • use only accounts you own or have explicit permission to use;
  • access, view, or store only the minimum information strictly necessary to demonstrate the issue;
  • stop testing and notify us immediately if you encounter personal data, secrets, credentials, or data belonging to other users;
  • not retain, copy, disclose, modify, delete, corrupt, or exfiltrate data;
  • not disrupt or degrade the Service;
  • not attempt denial-of-service, traffic flooding, destructive testing, persistence, malware deployment, or lateral movement;
  • not use social engineering, phishing, coercion, bribery, impersonation, or physical intrusion;
  • not target users, staff, contractors, suppliers, or third-party providers;
  • comply with applicable Italian, EU, and local law.

Activities outside this policy are not authorised.

4. Scope of testing

In scope

The following are in scope:

  • the public FreedivingHome service at freedivinghome.com;
  • subdomains expressly listed as in scope in the published security.txt file, if any;
  • authentication, authorisation, session, and access-control issues;
  • server-side input handling, output handling, and upload handling;
  • application-layer vulnerabilities with demonstrated impact, including access-control flaws, injection flaws, cross-site scripting, cross-site request forgery, server-side request forgery, insecure direct object references, and business-logic flaws.

Out of scope

The following are out of scope:

  • denial-of-service, stress, load, or volumetric testing;
  • physical intrusion or network-level intrusion;
  • social engineering, phishing, or targeting of users, staff, contractors, or third parties;
  • testing of third-party services, infrastructure, providers, or platforms;
  • issues affecting only unsupported browsers, rooted or jailbroken devices, or hostile networks controlled by the tester;
  • reports based only on automated scanner output without demonstrated impact;
  • self-XSS without a realistic attack path;
  • missing or non-optimal security headers without a demonstrated exploitation path;
  • clickjacking or framing issues without a demonstrated sensitive action or impact;
  • rate-limit observations without a demonstrated abuse scenario;
  • user-enumeration claims without a demonstrated security or privacy impact;
  • email-authentication issues on domains not used for sending mail;
  • recently disclosed third-party vulnerabilities already under review or remediation;
  • theoretical issues without a practical impact on FreedivingHome or its users.

If you are unsure whether testing is in scope, ask first.

5. Security posture

The measures below are summarised at a high level. Specific implementation details are intentionally omitted from this public page.

Authentication and access

  • Passwords are stored using a salted password-hashing function selected and configured to resist offline attack.
  • Email verification is required for account activation.
  • Additional account-protection features may be made available where supported.
  • Authentication and other sensitive actions are protected by rate limits and abuse controls.
  • Production access is restricted to authorised operators, protected by individual credentials and additional authentication controls.
  • Privileged access is limited to what is necessary for operation, maintenance, security, and incident response.

Transport and storage

  • Traffic to the Service is served over TLS.
  • Plain HTTP requests are redirected to HTTPS.
  • Confidential data and backups are protected at rest.
  • Secrets are kept outside source control and are rotated when appropriate.

Application security

  • The application uses input validation, output encoding, request validation, and safe data-access patterns.
  • Uploaded files are subject to automated malware screening before being made available.
  • A Content-Security-Policy and additional browser security headers are configured to reduce common attack paths.
  • Dependencies and platform components are monitored for security advisories and updated according to risk.

Logging and monitoring

  • Operational and security events are logged to support abuse detection, troubleshooting, and incident investigation.
  • Logs are limited to what is necessary for those purposes.
  • Access to logs is restricted to authorised operators.

Backups and recovery

  • Backups are encrypted and managed separately from production access.
  • Backup access is restricted to authorised operators.
  • Recovery procedures are documented and tested periodically in a non-production manner where practical.

Incident response

  • Security incidents are handled under an internal process covering triage, containment, evidence preservation, remediation, communication, and recovery.
  • Where legal thresholds are met, notifications to regulators or affected users will be made in accordance with applicable law, including GDPR Articles 33 and 34 where relevant.

6. Acknowledgments

With your permission, we may publish the name or handle of researchers who responsibly disclose valid, previously unknown, and actionable vulnerabilities.

Acknowledgment is discretionary and may be withheld where a report is abusive, duplicative, out of scope, unlawful, or inconsistent with this policy.

We do not currently operate a paid bug-bounty programme. No monetary reward is offered unless expressly agreed in writing before testing.

7. Machine-readable information

A machine-readable security.txt file is published at: https://freedivinghome.com/.well-known/security.txt

The file is served over encrypted transport and kept current. It includes at least the appropriate contact and policy information, and may include additional fields such as canonical location, expiry, preferred language, encryption, and acknowledgments, where operationally supported.

If there is any inconsistency between this page and security.txt, this page controls unless the inconsistency is clearly caused by this page being outdated.

8. Changes to this policy

This policy may be updated to reflect legal, operational, or security changes.

Material updates will be dated and summarised on this page where practical.

9. Contact

[email protected]