Protect the owner boundary.

Public data

Published profile fields and enabled links

Private action

Creating, editing, exporting, and deleting account data

Identity

Authenticated account ID and provider session

Authorization

Database rules tied to account ownership or an owner allowlist

• Collect only account, profile, support, and operational data needed to run the service.
• Keep server admin credentials and privileged backend operations out of browser code.
• Treat client-side redirects and hidden controls as user experience, never as the authorization boundary.
• Keep dependencies current, review Security Rule changes, and test both allowed and rejected operations.

Socialize is not a secure vault. Public profile content should be assumed discoverable and copyable. Never publish credentials, private repository tokens, identity documents, client secrets, or confidential contact details in a profile.

Authentication

Email, Google, and GitHub sign-in are handled through Socialize's authentication layer. OAuth providers authenticate users on provider-controlled pages. Socialize should not receive or store Google or GitHub passwords.

Authorization

A signed-in session proves which user is present. Database security rules and trusted server operations must verify that the user owns the requested profile before a write, export, account change, or deletion. A guessed handle or document path must not grant access.

Operational access

Production console, backend, domain, deployment, and support access should use individual accounts, multi-factor authentication where available, least privilege, and prompt removal when access is no longer needed. Privileged actions should leave an auditable provider record.

Transport and storage

Production traffic should use HTTPS. Cloud and hosting providers supply platform-level transport and storage protections. Socialize must still configure access rules, retention, backups, secrets, and provider permissions correctly.

The self-hosted edition uses a privateowners/{uid} database allowlist for private writes. The included rules allow public reads from the profile collection and deny writes unless the signed-in UID has a matching owner document. The public interface renders a configured fallback when the cloud backend is unavailable.

• Create owner allowlist documents only from your backend dashboard or other trusted administration tooling; browser clients cannot grant access.
• Deploy and test firestore.rules. A local rule file does not protect production until it is deployed to the correct project.
• Add only the intended owner UID and delete its allowlist document immediately when that identity is lost or compromised.
• Add only the required authorized sign-in domains and keep GitHub OAuth callback URLs exact.
• Patch Next.js, backend dependencies, and other packages; monitor your hosting and backend usage for unexpected activity.
• Back up profile data and test restoration without exposing it in a public repository.

A vulnerability in code shipped by Socialize can be reported to the address below. Compromise caused by a fork's custom code, provider account, secrets, rules, deployment, or domain must also be handled by that operator and the relevant provider.

Email llewellynpaintsil34@gmail.comwith a clear subject. Do not open a public issue for an unpatched vulnerability. If ordinary email is unsuitable, ask for an encrypted reporting channel before sending sensitive evidence.

• The affected hostname, route, repository file, or commit.
• Impact and the conditions required to trigger it.
• Numbered reproduction steps and a minimal proof of concept.
• Whether any account or personal data was accessed, changed, or exposed.
• Your preferred name, contact method, and disclosure timeline.

Remove tokens, passwords, cookies, and unrelated personal data from screenshots or logs. If a secret belonging to you was exposed during testing, revoke it before sending the report.

Intended in scope

• Managed Socialize web properties owned and operated by the project.
• Authorization failures that expose or modify another hosted account.
• Authentication bypass, session compromise, stored cross-site scripting, or server-side injection.
• Public-template defects that create a vulnerability in an unmodified self-hosted deployment.
• Exposed Socialize-owned production secrets or privileged infrastructure access.

Not authorized without written permission

• Denial-of-service, load, stress, or resource-exhaustion testing.
• Social engineering, phishing, bribery, threats, or physical intrusion.
• Testing Google, GitHub, a hosting provider, or another third party.
• Accessing another user's account, private data, or linked service.
• Testing a self-hosted instance without permission from its operator.
• Automated scanning that generates excessive traffic or creates accounts in bulk.
• Publishing a vulnerability before coordinated disclosure is complete.

A public profile containing prohibited content is an abuse report, not necessarily a product vulnerability. Use the handle-specific reporting guide for that case.

When research follows this policy, is carried out in good faith, avoids privacy harm and service disruption, and is reported promptly, Socialize intends to treat it as authorized security research and not pursue legal action for accidental, good-faith violations of this policy.

Stop testing and report immediately if you encounter personal data, credentials, or access beyond accounts you control. Do not retain, download, alter, or disclose more data than necessary to demonstrate the issue. Give Socialize a reasonable opportunity to investigate and fix a confirmed vulnerability before public disclosure.

This policy cannot authorize activity against third parties, excuse violations of law, or bind law-enforcement authorities. It is offered by Llewellyn Adonteng Paintsil for testing of the managed Socialize service only.

For a confirmed incident, the intended process is to restrict affected access, preserve relevant evidence, revoke exposed credentials, patch the cause, validate the fix, and monitor for recurrence. Notification to affected users and authorities will follow applicable law and the risk presented by the incident.

Public updates should distinguish known facts from investigation and avoid details that expose users or enable active exploitation. A final review should identify control, process, and documentation improvements.