Security

01Current security scope

PostingZone currently serves a static website and a browser-local demonstration. There is no PostingZone account database, social-token store, AI backend, or publishing worker connected to the demo. Sample approval decisions, analytics, and account connections change local interface state only.

The public website is delivered over HTTPS through Cloudflare Workers. Its preview login form does not authenticate anyone or restrict access to the public pages. This page does not claim a security certification, penetration-test result, availability SLA, or independently audited production system.

02Local storage and device access

The workspace stores demo changes under the browser key postingzone-demo-v1. The theme is stored separately. Local storage is readable by code running on the same site origin and by people with access to your browser profile. It is not an encrypted vault or a replacement for secure server-side storage.

Do not enter credentials, private customer lists, identity documents, confidential agency work, or other sensitive material into the demo. On shared devices, clear site data after use. Reset demo data restores the sample workspace, while clearing all site data also removes preferences and may affect the hosting session.

03Transport and infrastructure

HTTPS protects network transport to the published site. Site availability, edge delivery, and provider-level session behavior are operated by the hosting provider. Google Fonts and external destinations use their own infrastructure and policies.

Before live data processing, transport security must cover every API and provider connection. Encryption at rest, backup protection, key management, network isolation, and recovery procedures must be implemented and verified for the actual architecture. Their inclusion here is a launch requirement, not a statement that an unused backend already has those controls.

04Identity, roles, and access controls

The demo has no authenticated team membership or production permissions. Future workspaces must enforce access checks on the server, isolate organizations, and restrict account administration, review, publishing, and billing actions to authorized roles.

Administrative access should use strong authentication, least privilege, separate operational credentials, and access reviews. Recovery and session-revocation processes must be tested. A visible button or client-side toggle is not an authorization boundary, so the production system must verify permissions independently of its interface.

05Social permissions and token handling

No real social token is collected by the present demo. The Accounts screen demonstrates sample connections, and social buttons open the PostingZone profile URLs. They do not request platform permissions.

Before live OAuth connections, PostingZone must explain requested scopes and use only the permissions necessary for the selected features. Credentials and refresh tokens must be kept out of URLs, browser storage, public source, and application logs. Server-side tokens must be protected with restricted access and appropriate encryption.

Disconnecting a live account must delete or revoke stored authorization as appropriate and prevent pending publishing jobs from using it. Revocation in the platform’s own settings must also be respected. Exact behavior will depend on platform APIs and must be tested before connection is offered.

06Publishing integrity and review

Approval is required in the demonstrated workflow. No demo action publishes to a social network. Editing or moving a sample draft sends it back to a draft state so its contents and date can be reviewed again.

A live service must tie approval to the exact version of a caption, visual, target account, and scheduled time. Changes must invalidate stale approvals where necessary. Server-side jobs must recheck authorization, prevent unintended duplicate delivery, and record the outcome. A successful animation is not evidence of a completed platform request.

07Vendors and payment boundaries

The public deployment is hosted on Cloudflare Workers and its delivery infrastructure. Licensed font files are served from the same website origin. Photographs are hosted as local optimized assets. Stripe is a planned payment provider, not a live payment flow in the current configuration.

Provider contracts, processing locations, retention, and transfer arrangements must be confirmed before customer data is sent. Future checkout should keep full card details in the payment provider’s interface. Never send full card numbers, security codes, passwords, or access tokens in a support request. AI providers and social networks must be assessed separately when selected.

08Monitoring, maintenance, and recovery

The application does not currently maintain production security audit logs or a customer-data backup service. Hosting providers may maintain their own operational logs. There is no promise of round-the-clock monitoring or a particular incident response time.

Before commercial launch, the operator must define dependency review and patching, secret handling, sanitized logging, alerting, backup retention, restore testing, and incident ownership. Logs should contain only what is needed, with restricted access and defined deletion periods. Recovery targets must be communicated only after they have been validated.

09Incidents and vulnerability reports

If you identify an issue, use the operational security or contact route once configured. Include the affected URL, a concise description, minimal reproduction steps, approximate time, and the likely impact. Redact tokens, personal records, and unrelated confidential information from evidence.

Test only systems and accounts you are authorized to use. Stop if testing exposes someone else’s data. Do not disrupt availability, download customer datasets, or publish exploit details before the issue has been assessed. This page does not offer a bug bounty or grant blanket permission for security testing.

For a future service, the operator must investigate confirmed incidents, contain exposure, and give affected people or authorities notices when required. A notification timeline depends on the applicable obligations and facts; no unsupported universal deadline is promised here.

10Your security responsibilities

Keep your browser and device updated, restrict access to shared profiles, and preserve a separate copy of important content. Verify the destination before following a payment or sign-in link. Use a strong unique password and available multifactor protections for any external account.

Review permissions before connecting a future social account and remove access when it is no longer needed. Check a draft’s factual accuracy, privacy, rights, and target account before approval. The Privacy Policy and Cookie Policy explain data handling and local storage controls in more detail.