Account & access security
Paid features, account ownership and sensitive actions should be authenticated and authorized by the production backend rather than trusted from browser state alone.
BIZCITY / SECURITY
Trust The Link. Protect The Journey.
BizCity is designed around a simple security principle: links, QR codes, accounts, domains, payments and analytics should be protected at the point where they are created, managed and used.
OUR SECURITY PRINCIPLE
Security claims should be as real as the data.
BizCity is being built as a production link-management platform, which means security has to cover more than a login form. Redirects, QR destinations, branded domains, analytics events and paid account access all create different trust boundaries.
The goal is to enforce sensitive controls on the server, not rely on browser-side checks alone. Where a production control is still being implemented, BizCity should describe it as planned or required rather than presenting it as already active.
This page describes BizCity's intended security architecture and operating principles. Features should only be treated as active controls once they are implemented and verified in production.
SECURITY AREAS
Protection across the whole link lifecycle.
Redirect integrity
Short links should resolve through controlled server-side routing so the destination, ownership and tracking behavior can be validated before redirecting a visitor.
Branded-domain verification
Custom domains should only be activated after the expected DNS or ownership checks have been completed and associated with the correct BizCity account.
Dynamic QR control
Dynamic QR codes should route through BizCity-controlled redirects so destination changes and tracking access remain tied to authenticated account permissions.
Payment separation
Payment credentials should remain with the payment provider. BizCity should work with payment references and verified status rather than asking users for PayPal passwords or full card details.
Privacy-aware event tracking
Analytics should collect only the event information needed for useful reporting and should avoid storing unnecessary sensitive visitor information.
DATA & PRIVACY
Collect what is useful. Avoid what is unnecessary.
The planned analytics architecture can use a one-way visitor hash derived from request characteristics and a server-side secret instead of retaining raw IP addresses for uniqueness calculations.
Clicks and QR scans should come from actual tracked events. Missing or unavailable analytics should remain empty rather than being replaced by fabricated metrics.
Useful reporting may include country, device class, browser, operating system, referrer, campaign parameters and event time when those attributes are legitimately available.
API secrets, payment credentials and security keys should remain in protected server configuration and should not be exposed inside public HTML or browser JavaScript.
LINK & QR SAFETY
A short URL should not become a blind spot.
Link-management platforms need controls for ownership, abusive destinations, account permissions and redirect behavior because the final destination is not always visible from the short URL itself.
Destination validation
Production link creation should validate supported URL formats before storing or publishing redirects.
Account ownership
Editing, deleting or viewing protected analytics should require the authenticated account to own or have permission to access the asset.
Abuse prevention
BizCity should maintain controls for detecting and responding to phishing, malware, spam, impersonation and other prohibited link usage.
Request protection
Authentication, creation and API endpoints should use reasonable rate limits and validation to reduce automated abuse and resource exhaustion.
Verified custom domains
A branded domain should not become active simply because a user entered its name; DNS or ownership verification should be completed first.
Operational visibility
Security-relevant backend events should be logged in a way that helps investigate failures and abuse without unnecessarily exposing sensitive data.
PAYMENT SECURITY
Your payment credentials should stay with the payment provider.
BizCity's current pricing flow can send customers to PayPal for payment. The BizCity page should not request or store a customer's PayPal password.
Paid access should only be enabled after the business has a reliable way to verify the payment or subscription status. A browser redirect or client-side success message alone should not be treated as proof of entitlement.
Never send PayPal passwords, full card numbers, security codes or other payment credentials through a BizCity support form.
PRODUCTION SECURITY DIRECTION
Controls that belong on the backend.
Authenticated account access for protected actions, paid features and asset ownership.
Server-side checks before reading, editing or deleting links, QR assets, domains and analytics.
Request validation for URLs, aliases, domain records, API inputs and support submissions.
Reasonable protection for login, link creation, APIs and other endpoints exposed to automated requests.
Payment secrets, API keys and application secrets kept outside public client-side code.
Production web and API traffic should use HTTPS with valid certificates on supported domains.
Production data should be backed up according to an operational recovery plan appropriate to the service.
Application errors, abuse indicators and service health should be monitored so problems can be investigated quickly.
RESPONSIBLE DISCLOSURE
Found a security issue?
If you believe you found a security vulnerability in BizCity, report it through Support with enough detail for the issue to be reproduced. Do not include passwords, private keys, payment credentials or unnecessary personal data.
Describe the affected page, endpoint, short link or feature.
Include clear reproduction steps and the observed result.
Explain the potential impact without accessing data you do not own.
Avoid destructive testing, service disruption or privacy violations.
SECURITY & TRUST
Build useful tools without hiding the security boundaries.
BizCity's security direction is to keep sensitive controls server-side, collect only useful analytics data and be transparent about what is active, planned or unavailable.
SECURITY FAQ
Security questions.
A quick explanation of how BizCity approaches account, link, QR, analytics and payment security.
Does BizCity store my PayPal password?
No. PayPal authentication and payment details are handled by PayPal. You should never send your PayPal password through a BizCity form or support request.
Are paid account limits protected only by browser storage?
They should not be. Browser-side limits are useful for front-end demonstrations, but production paid entitlements and usage limits should be enforced by the authenticated BizCity backend.
How does BizCity approach visitor analytics privacy?
The planned tracking architecture is designed to use privacy-aware event data and can use a one-way visitor hash instead of retaining raw IP addresses when that is sufficient for uniqueness calculations.
Can anybody connect a branded domain?
A production branded domain should only be activated after the required DNS or ownership verification succeeds and the domain is associated with the correct authenticated account.
How should BizCity protect short links from abuse?
The production platform should combine URL validation, authentication, account ownership controls, rate limiting, abuse reporting and operational review for prohibited destinations such as phishing or malware.
Does BizCity expose backend API secrets in the browser?
Sensitive production secrets should remain in protected server configuration and should not be embedded in public HTML or browser JavaScript.
How can I report a security vulnerability?
Use the BizCity Support page and provide clear reproduction steps, the affected feature and the potential impact. Do not send passwords, private keys or payment credentials.
Is every control described on this page already active?
No claim should be assumed beyond what is implemented in production. This page intentionally distinguishes BizCity's security architecture and required controls from features that may still be under implementation.