適切な人にだけ リンクを共有

Password protection adds a gate in front of a short link: visitors must enter the correct password before they are redirected to the destination. It is a simple feature with one honest purpose—keeping casual or accidental access out—and MiniLy includes it on every plan, including Free, at no extra cost.

It is worth being precise about what this is. Password protection controls access to the redirect; it is access control for the link, not encryption of the destination content itself. Anyone who knows the password can reach the destination. Used for that purpose, it is genuinely useful and the security underneath is solid.

Passwords are hashed with bcrypt at 12 salt rounds—the OWASP-recommended configuration—so they are never stored in plain text, and the password never appears in the URL or browser history.

You add a password to any of your short links from the dashboard in one step. When someone opens the link, they land on a dedicated password page instead of being redirected immediately. Enter the correct password and the redirect proceeds; enter the wrong one and access is denied.

• Hashing: bcrypt with 12 salt rounds; the plain-text password is never stored.
• No URL exposure: the password is entered on a separate page, never embedded in the link, so the link is safe to share publicly.
• Rate limiting: repeated wrong guesses on a protected link are blocked automatically, which makes brute-force attempts impractical.
• Editable anytime: change or remove the password whenever you like; changes take effect immediately.

Analytics still work—each successful visit is recorded with the usual location, device, and referrer data.

Password protection suits content meant for a known audience rather than the open web:

• Confidential documents: reports and internal memos shared with authorized recipients only.
• Private events: RSVP forms or surprise-party details behind a shared password.
• Exclusive content: reward subscribers or VIP members with gated access.
• Client deliverables: proposals and invoices sent with a per-client password.

Be realistic about what this protects. It is a single shared password per link—there are no per-user accounts, no individual revocation, and no audit trail of who entered the password. If you share the link and password with ten people, you cannot later cut off one of them without changing the password for all. The strength of the gate also depends on the password you choose; bcrypt and rate limiting protect against brute force, but a weak or widely shared password is still weak.

This is access control on the redirect, not end-to-end encryption of whatever sits at the destination, and it does not protect content hosted elsewhere. There is no expiring-link or one-time-use option tied to the password, and no public API to manage protection programmatically. For genuinely sensitive data, treat it as a deterrent layer, not a vault.