Security warning

Problem Context

• The risk may be phishing, social engineering, malware, unwanted software, dangerous download, scareware, invalid certificate, insecure connection, mixed content, unsafe form action, suspicious redirect, file preview risk, compromised site, unknown publisher, or account takeover signal.
• Users may be navigating from email, search, chat, ads, QR codes, embedded links, downloads, file previews, admin consoles, password reset flows, payment forms, or internal tools.
• The product may need different outcomes for block, warn, details, report false positive, report phishing, back to safety, open settings, contact administrator, delete file, keep file, use trusted route, or continue with an audited override.
• Security warnings must be noticeable without becoming habituating; routine warnings, fake security copy, and easy bypasses train users to ignore real risk.

Selection Rules

• Choose security warning when the system has a security-risk signal and proceeding could expose credentials, personal data, payment data, device integrity, account access, or organization assets.
• Use a blocking interstitial when navigation, submission, download, preview, or launch would immediately put the user in a risky context before the normal task can continue.
• Name the risk type in user language: deceptive site, suspected phishing, malware suspected, dangerous download, certificate problem, insecure connection, suspicious redirect, or unsafe form submission.
• Show the destination, file, certificate, publisher, source URL, redirect target, or account event when safe to reveal, and redact sensitive values when the warning itself could leak private information.
• Make the safe action primary, such as Back to safety, Remove download, Cancel submission, Use trusted site, Open settings, Contact admin, or Review activity.
• Place override behind Details, More information, administrator policy, or a secondary action that states the risk; do not present Continue as the default action.
• Use warning text when the issue is a known consequence before a product action rather than a detected active security threat.
• Use alert when a current-task status needs urgent notice but the task can continue safely without a security interstitial.
• Use permission denied state when access is blocked by authorization rather than unsafe trust, malware, phishing, or transport security evidence.
• Use sensitive-data reveal when the main task is controlled exposure of a value already held by the product, not warning about an unsafe destination or object.
• Use site alert when the security message applies across a whole service and does not block one risky navigation, file, form, or action.
• Do not let the warning collect passwords, payment data, recovery codes, or other secrets; route users to a verified destination for remediation.

Required States

• Safe path state with primary Back to safety, Cancel, Remove, Use trusted route, or Contact admin action.
• Detected phishing or deceptive-site state.
• Malware or dangerous-download state.
• Invalid certificate or connection-not-secure state.
• Mixed-content or unsafe form-submission state.
• Suspicious redirect or lookalike-domain state.
• File preview blocked or unknown publisher state.
• Details expanded state with evidence, affected object, and why override is risky.
• Override requested state with deliberate secondary action, policy check, or administrator gate.
• Override blocked by organization policy state.
• False-positive or report-site state that does not require users to visit the unsafe destination.
• Dismissed safe-return state that preserves safe draft context and removes dangerous content from view.
• Mobile compact state where risk, destination, primary safe action, and details remain readable.

Interaction Contract

• The warning appears before the risky navigation, submission, download open, file preview, install, or sensitive account action completes.
• The first heading or announcement names the security risk, not only a severity word.
• The safe action is visually and semantically primary, receives the clearest label, and returns users to a safe context without losing recoverable safe work.
• Details disclose evidence such as domain mismatch, certificate problem, file reputation, redirect target, insecure form action, or detection source without exposing raw secrets.
• Override, when allowed, requires an explicit secondary path and may require administrator approval, policy acknowledgement, or audit logging.
• If policy blocks override, the state explains the boundary and provides a support or administrator path instead of a disabled button alone.
• Report false positive, report phishing, and site-owner remediation routes are separated from Visit anyway.
• Security-warning text is not reused for fake urgency, marketing pressure, routine maintenance, validation, or optional consent.

Implementation Checklist

• Classify security warning triggers by threat type, evidence source, confidence, affected object, safe default action, override policy, reporting path, and audit requirement.
• Render risk-specific headings, destination/file identity, consequence copy, primary safe action, details, and any allowed override consistently across web, mobile, and desktop surfaces.
• Use server, browser, operating-system, or security-service verdicts as authoritative signals; avoid client-only cosmetic security warnings for real threats.
• Keep dangerous content, preview, script, download open, form submission, or credential entry blocked until the user chooses a permitted path.
• Log warning shown, safe return, report, override request, override allow or block, policy reason, and affected object without logging secrets.
• Preserve safe drafts and return targets, but clear or quarantine unsafe content according to threat policy.
• Test phishing links, lookalike domains, malware downloads, unknown publishers, invalid certificates, mixed-content submissions, redirects, false-positive reports, admin override policy, mobile wrapping, keyboard access, and screen reader announcement.

Common Generated-UI Mistakes

• Using vague warning copy that does not say phishing, malware, certificate, insecure connection, dangerous download, or suspicious redirect.
• Making Continue the primary or only visible action.
• Showing the warning after credential entry, file execution, form submission, or preview rendering already happened.
• Hiding destination, file, publisher, redirect, or evidence details that users need to make a safe choice.
• Using fake security urgency to pressure consent, upgrade, payment, or marketing decisions.
• Letting every low-risk informational notice use the same severe security-warning treatment.
• Logging raw passwords, tokens, payment data, or private file contents while producing the warning.

Critique Questions

• What concrete security signal caused this warning, and how fresh is it?
• What exact navigation, download, submission, preview, install, or account action is being stopped?
• Can the user identify the unsafe destination or object without exposing private information?
• Is the safe action clearly primary, and does it preserve safe task context?
• Is any override necessary, policy-allowed, deliberate, and auditable?
• Does the warning offer a false-positive, report, administrator, or site-owner remediation path?
• Could this warning train users to ignore real security risk because it is overused or vague?