Security

Application security

• FourLook supports authenticated admin access, password hashing, permission checks, session handling, and clean separation between public tracking routes and admin tools.
• Security-sensitive files, scripts, configuration, and storage paths should be blocked from public web access in production.

Data protection

• Production deployments should use HTTPS, secure database credentials, restricted server access, regular backups, patched dependencies, and least-privilege operational access.
• Customers should avoid storing sensitive payment data, health data, government IDs, or other regulated data inside tracking parameters or campaign names.

Responsible disclosure

• If you believe you found a vulnerability, email [email protected] with details and steps to reproduce. Do not access customer data or disrupt service while testing.

Account security

• Administrators should use strong unique passwords, limit user permissions, remove inactive users, and protect admin login URLs and server credentials.
• Customer login and owner/admin login remain separate to reduce risk between customer workspaces and core system access.

Infrastructure security

• Production deployments should use HTTPS, secure file permissions, protected configuration files, restricted database access, patched PHP and server packages, backups, and monitoring.
• Public web roots should not expose backups, logs, migration files, credentials, vendor internals, shell scripts, or environment files.

Tracking domain security

• Custom domains should be verified before use. DNS records should point only to authorized servers, and SSL certificates should be issued and renewed through trusted certificate authorities.
• If a domain is lost, compromised, expired, or repointed, it should be removed or disabled promptly to prevent abuse.

Incident response

• Potential incidents may include unauthorized account access, exposed credentials, abnormal redirect behavior, suspicious postbacks, domain takeover, malware reports, or data access anomalies.
• When a security incident is confirmed, we aim to investigate, contain, remediate, document, and notify affected parties as required by law and contract.

Responsible disclosure rules

• Do not perform destructive testing, denial-of-service testing, social engineering, spam, phishing, physical attacks, or attempts to access customer data.
• Reports should include affected URL, vulnerability type, impact, reproduction steps, screenshots or proof of concept, and your contact information.

Customer security responsibilities

• Customers must protect API keys, postback secrets, ad platform credentials, network credentials, destination pages, and any third-party scripts connected to campaigns.
• Customers should review reports, domain status, campaign destinations, and user access regularly for suspicious behavior.