[Admin] Restrict sensitive email contents to superadmins

[garyhtou]

Summary of the problem

The admin email viewer renders the stored copy of every email HCB sends. The admin area is gated by signed_in_admin, which resolves to auditor_signed_in?, so the read-only auditor role could open any of them.

LoginCodeMailer#send_code puts the login code in the subject as well as the body, and the subject is stored unencrypted and exposed through search, so the code was visible on the index page without opening anything.

The 15 minute code expiry gave no protection, because the attacker chooses when the code is generated: enter a victim's email at /logins, then read the fresh code off the admin page. Unlike impersonation, which stamps user_sessions.impersonated_by, the resulting session is indistinguishable from the real user's.

Two other mailers store secrets in the same table: GSuiteAccountMailer (plaintext Google Workspace passwords, which do not expire) and User::EmailUpdateMailer (email change tokens).

Describe your changes

Mailers opt in with has_sensitive_contents, a thin wrapper over ahoy_email's has_history that stamps a new ahoy_messages.sensitive column at delivery. Existing rows are backfilled. Every admin read path then checks superadmin_signed_in? before disclosing anything:

• #email and #email_html return 403 for a flagged message unless the viewer is a superadmin. This is the fix; the rest is presentation.
• The index renders the mailer and action (LoginCodeMailer#send_code) in place of the subject, and its modal explains the restriction rather than loading the email.
• Flagged rows are excluded from subject search for non-superadmins. The subject is plaintext and searchable, so without this you could confirm a live code from the result count alone.

superadmin_signed_in? is used rather than current_user.superadmin? because it also rejects impersonated sessions, so an admin impersonating a superadmin is denied.

Nothing changes about what is stored. Contents stay encrypts-protected and fully readable from the Rails console, and superadmins keep access in the UI.

Since marking is opt in, a new secret-bearing mailer would default to visible. spec/mailers/sensitive_contents_coverage_spec.rb pins the current set of mailer actions so adding one fails the suite with instructions. It is a tripwire to force a decision on anything new, not a certification that all 151 existing entries were individually audited.

Deploy order

1. Run the migration. It only adds a column with a constant default, so there is no table rewrite.
2. Deploy the code.
3. Run Maintenance::BackfillSensitiveAhoyMessagesTask to flag historical rows, then run it again once the release is live to catch anything sent during the deploy window.

The migration must land before the code. AhoyEmail::Tracker wraps message creation in Safely.safely, so if the code ships first, assigning the unknown attribute is swallowed and no Ahoy::Message row is written at all for these mailers. That fails closed for confidentiality but silently loses the record that the email was sent.

Backfilling from a maintenance task rather than a migration keeps a long update over a large table out of the deploy, and makes it pausable, throttleable and re-runnable.

This does not close the underlying hole

Auditors also have Blazer (config/routes.rb, constraints AuditorConstraint), which runs arbitrary SQL against the app's own database with no table restrictions. login_codes.code is stored in plaintext, so the same actor can skip the email viewer entirely and read live codes with a query. ahoy_messages.subject is a second path to the same secret.

This PR is still worth landing, since the email viewer was exposing Workspace passwords and email change tokens as well, and to more people. But the account takeover path stays open until login codes stop being readable as plaintext, or Blazer stops running as a role that can read them. Raising that separately.

Testing

20 new examples covering the flag being written at delivery, 403s for auditor / admin / impersonated-superadmin and a 200 for a genuine superadmin, the subject not appearing in the index for non-superadmins, and the search exclusion. The neighbouring mailer and admin suites still pass.

[github-actions]

Suggested change

	data: { behavior: "modal_trigger", modal: "message_#{msg.id}" } do %>
	data: { behavior: "modal_trigger", modal: "message_#{msg.id}" } do %>