Security

Anything that lets someone do what they should not be able to do on linkinseconds.com or our APIs. For example:

• Reading, changing or deleting a file, link, album or account that is not yours, or bypassing a link control such as a password, expiry date, view limit, email gate, view-only mode or a disabled link.
• Getting past the free-plan limits or Pro checks from the client, or getting Pro without paying.
• Running script as our origin (stored or reflected cross-site scripting), including through an uploaded file.
• Reaching admin pages, cron endpoints or another user's session, or finding a leaked secret, key or token.
• Server-side request forgery, injection, authentication or authorisation flaws, and insecure direct object references.

Email support@linkinseconds.com with the subject line "Security". Please include:

• What the issue is and what it lets an attacker do.
• Steps to reproduce it: the exact URLs or requests, and a proof of concept if you have one. Screenshots or a short recording help.
• Which accounts or test links you used, so we can check our logs.
• How you would like to be credited, or that you prefer not to be.

Please use your own accounts and your own test files. If you need to prove access to someone else's data, stop at the first evidence and tell us; do not download, keep, share or alter it.

• A reply within 3 business days acknowledging your report and who is handling it.
• An honest assessment of severity, a fix timeline, and a note when it has shipped. Critical issues are fixed as a priority.
• No legal action against you for research done in good faith and within the scope below.
• Credit on request once the issue is fixed. We are a small company and do not currently run a paid bug bounty, but we do say thank you.

In scope: linkinseconds.com (including the app, the public file pages, the APIs and the admin area), linkinseconds.site hosted sites, and the official email we send.

Out of scope:

• Denial of service, resource exhaustion, brute force, rate-limit testing at volume, or anything that degrades the service for real users.
• Social engineering, phishing or physical attacks against our staff, our users or our providers.
• Third-party providers we build on (Vercel, Supabase, Cloudflare, Dodo Payments, Resend, Google, Microsoft Clarity, PostHog). Report those to the provider directly.
• Findings that need a compromised device, a rooted phone, a malicious browser extension or physical access to the victim.
• Reports from automated scanners with no working proof of concept, missing best-practice headers with no demonstrated impact, clickjacking on pages with nothing to click, and email SPF, DKIM or DMARC configuration notes.
• Content that a user uploaded. Abuse of the service by its users is handled on our Report Abuse page, not here.

If you make a good-faith effort to follow this policy, we consider your research authorised. We will not pursue or support legal action against you under computer misuse or anti-circumvention laws for that research, and if a third party starts legal action against you for activity that followed this policy, we will make it known that you acted in line with it. Good faith means: you stay within the scope above, you only access the minimum data needed to show the issue, you do not exploit it beyond that proof, you give us a reasonable time to fix it before any public disclosure, and you do not demand payment as a condition of telling us.

A short summary, in plain words. The full detail lives in our engineering docs.

• Private storage, gated serving. File bytes live in a private bucket with no public URLs. Every view goes through our own server, which checks the link's controls (disabled, password, expiry, view limit, email gate, view-only, moderation status) on every request.
• Encryption. TLS for every connection, with HSTS, and encryption at rest for files and the database. Link passwords are stored as scrypt hashes; unlock cookies are signed and expire when the password changes.
• Isolated user content. Uploaded HTML renders only inside a sandboxed frame that cannot read our cookies or call our APIs as you. Files are checked by type and by their actual bytes; executables are refused.
• Sign-in. Google sign-in only, so there is no password of ours to phish. Sessions are cookie-based, secure and same-site.
• Abuse defence. Every upload is scanned for phishing, malware and unsafe content, with rate limits, a report button on every public page, and a moderation queue that can disable a link or an account at once.
• Least privilege. Row-level security on every table, server-only secrets, admin access limited to a fixed allowlist, and dependency updates with automated vulnerability alerts.
• Payments. We never see or store card details. Checkout and billing run with our payment provider as merchant of record.

Had a breach that affected you? We will tell you directly and without undue delay, as our Privacy Policy sets out.

Link in Seconds is operated by Radadiya Sunny Keshavbhai (Sole Proprietorship), based in Gujarat, India. Security reports go to support@linkinseconds.com with the subject "Security". For anything else, use our contact page.