Security & Responsible Disclosure Policy

1. Security principles

DFF Reach applies proportionate technical and organisational controls to the account, workspace, connection, publication, media, billing and support features that are actually released.

• Reusable social-provider authority is encrypted before database storage and is not returned in ordinary browser responses.
• Service, provider and encryption credentials are server-only and are not committed to public client bundles.
• Secure cookies, origin checks, bounded request bodies, provider callback validation and one-use transaction state protect sensitive flows.
• Database access controls and brand membership checks restrict private records to authorised users and trusted service processes.
• Production changes pass source, type, build and release checks before deployment.
• Security-relevant events are recorded in controlled audit data without intentionally logging passwords, full provider tokens or complete payment credentials.

2. Customer security responsibilities

Security is shared. Customers must use the service through the available protected interfaces and keep their own accounts and devices secure.

• Use a unique password and enable two-step verification where available.
• Do not share a Reach login, authenticator code, recovery link, payment credential or provider token.
• Keep team membership and brand permissions current.
• Disconnect provider access that is no longer needed and review the provider's own authorised-app settings.
• Report suspected account compromise promptly and preserve relevant timestamps or support references.

3. Reporting a suspected vulnerability

Email support@directfoodfinder.com with the subject “DFF Reach security report”. Provide a concise description, the affected URL or feature, reproducible steps, observed impact and a safe proof of concept. Include contact details if you want a response.

Do not send a live password, complete access token, private encryption key or unnecessary personal information in ordinary email. State that sensitive evidence is available and request a protected transfer route.

4. Good-faith research boundary

DFF Reach welcomes responsible reports based on good-faith, minimal-impact testing of accounts and data the researcher is authorised to use. Testing must stop when it could affect another user, reveal private information, damage data or reduce service availability.

• Use your own account, brand, provider test assets and non-sensitive test data.
• Make the smallest number of requests needed to demonstrate the issue.
• Avoid accessing, downloading, changing or deleting another person's data.
• Avoid broad automated scanning, denial-of-service activity, spam, resource exhaustion and persistence on a system.
• Do not use social engineering, credential stuffing, phishing, physical intrusion or attacks against employees, suppliers or users.
• Do not publicly disclose an unresolved issue before DFF Reach has had a reasonable opportunity to investigate and reduce the risk.

5. Out-of-scope reports

A report may still be useful, but the following are not normally treated as a security vulnerability without evidence of material impact.

• A missing optional header, low-risk version disclosure or theoretical best-practice observation with no exploit path.
• Rate-limit observations that do not enable account, data, billing or availability abuse.
• Self-XSS, clickjacking on a page with no sensitive action, or an issue that requires the victim to paste attacker code into a developer console.
• Provider behaviour wholly controlled by the provider and correctly represented by DFF Reach.
• An unavailable, disabled or visibly unreleased feature.

6. What DFF Reach will do

DFF Reach will acknowledge a credible report, triage the risk, preserve necessary evidence and communicate material progress where contact details are available. Response and remediation time depend on severity, reproducibility, provider dependencies and the safety of a fix.

DFF Reach does not currently promise a monetary bounty, reward or particular safe-harbour outcome. Nothing in this policy authorises conduct prohibited by law or by a third-party provider's rules. Good-faith compliance with this policy will nevertheless be considered when handling a report.

7. Security incidents and notifications

If DFF Reach confirms an incident affecting personal data or account security, it will contain and investigate the event and provide notifications required by applicable law or contract. Notices may be delivered by email, an in-product message or another appropriate channel.

Public status or incident information will avoid exposing details that would increase risk or reveal another user's private information.

8. Security statements and assurance

This policy describes current public practices; it is not a claim that DFF Reach holds a certification, attestation or government authorisation that has not been independently completed and published.

Business customers may request available security information through support. DFF Reach may withhold exploit details, secrets, another customer's information, privileged material and information that would weaken security.