Destination validation
Web destinations are validated and network protections help prevent unsafe internal-network targets. Validation is not a permanent guarantee that an external page will remain safe.
Security and trust
Know what protects a DrutoLink link, and where that protection ends
Security is an operating practice, not a badge. This page explains the controls DrutoLink applies today, the signals that remain estimates, and the responsibilities that stay with each link owner.
- 01
- Destination and request checks before redirects
- 02
- Plain IP addresses are not stored in analytics
- 03
- Bots and speculative requests are classified separately
- 04
- Public API keys, SSO, and enterprise governance are not available
Controls applied to links and redirect traffic
Several independent checks can affect whether a request reaches its destination.
Link state and access
Disabled, scheduled, expired, click-limited, unhealthy, or password-protected links can stop or delay a redirect according to their configured state.
Traffic classification
Request signals help separate likely human clicks, bots, blocked traffic, and speculative browser requests. Classification is heuristic and can be wrong.
Routing fallback
Geo, device, and experiment rules should retain a valid default destination. Location and device signals can be missing or imprecise.
Data and privacy boundaries
- DrutoLink hashes IP-derived analytics identifiers with a salt that changes daily instead of storing plain IP addresses.
- Guest links redirect without detailed analytics collection until an eligible link is claimed. Past guest traffic is not reconstructed.
- URLs, slugs, UTM values, referrers, and destination pages can expose information to browsers, recipients, logs, and analytics systems. Never place secrets or personal data in them.
- A click identifies a redirect event, not a verified person, consent record, purchase, or authenticated session.
What link owners still need to protect
A short-link control cannot replace security at the destination.
- 01Require destination-side authentication and authorization for confidential content.
- 02Keep passwords, tokens, personal data, and account identifiers out of URLs and UTM parameters.
- 03Test every active rule, fallback, expiry, and destination from representative devices and networks.
- 04Assign an owner who can disable the link, change a compromised destination, and respond to abuse reports.
- 05Use a visible first-party destination for payment, password reset, legal, or other high-trust workflows when the original domain is important to the decision.
Report a suspicious or abusive link
Send the complete DrutoLink URL, what you observed, and the approximate time of the event. Do not send passwords, payment details, private files, or other sensitive evidence by email.
Current limitations and planned controls
- Automated checks cannot guarantee that every destination is safe or available at every moment.
- Broad scheduled link-health monitoring and notifications remain incomplete.
- Public API keys, webhooks, SSO, audit-log exports, and enterprise policy controls are planned, not available.
- No certification, compliance scope, uptime percentage, or security response time is claimed on this page.
Security review before publishing
- 01Open the destination while signed out.
- 02Confirm HTTPS, ownership, and the final redirect chain.
- 03Remove sensitive query parameters.
- 04Test blocked, unknown, expired, and password paths.
- 05Verify the fallback destination.
- 06Record the owner and expected lifetime.
- 07Keep a fast disable and destination-replacement plan.