External links with target="_blank" missing rel="noopener noreferrer"

[akramcodez]

Problem

Several templates across Open Library use anchor tags with target="_blank" but do not include the recommended rel="noopener noreferrer" attribute.

This creates a reverse tabnabbing vulnerability, where the newly opened page can access window.opener and redirect the original tab to a malicious site.

Reproducing the bug

1. Navigate to: /account/create
2. Scroll to the “Terms of Service” section
3. Right-click → Inspect Element on the link

• Expected behavior:
  The anchor tag should include security attributes:

<a class="ol-signup-form__link"
   href="//archive.org/about/terms.php"
   target="_blank"
   rel="noopener noreferrer">
   Terms of Service
</a>

• Actual behavior:
  The anchor tag is missing the rel attribute:

<a class="ol-signup-form__link"
   href="//archive.org/about/terms.php"
   target="_blank">
   Terms of Service
</a>

Context

• Browser (Chrome, Safari, Firefox, etc):
• OS (Windows, Mac, etc):
• Logged in (Y/N):
• Environment (prod, dev, local): prod

Automated Detection

A test was added to scan templates for unsafe usage:

docker compose run --rm web pytest openlibrary/tests/test_templates.py::test_noopener_noreferrer

Result

• ~20 failing instances detected
• Confirms issue is widespread across templates

Affected Files (examples)

• openlibrary/templates/account/create.html
• openlibrary/templates/lists/lists.html
• openlibrary/templates/lib/exports.html
• openlibrary/templates/books/add.html
• openlibrary/macros/AffiliateLinks.html

Impact

• Enables reverse tabnabbing attacks
• External pages can manipulate the original tab using window.opener
• Considered a web security best practice violation

screenshot

[akramcodez]

I’d love to work on this, happy to fix all occurrences and include a test.

[mekarpeles]

Thank you @akramcodez for submitting this issue!

⚠️ Contributors, this issue will be ready to work on once:

• Triage — maintainers will add Priority: * and Lead: @* to replace Needs: Triage and Needs: Lead

---

Context

• A local grep of the codebase found 33 unsafe instances (not ~20 as stated), spanning 15 templates and 5 macros: macros/DonateModal.html, macros/LocateButton.html, macros/ShareModal.html, macros/AffiliateLinks.html, macros/EditButtons.html, templates/work_search.html, templates/widget.html (6 instances), templates/book_providers/read_button.html, templates/lists/lists.html, templates/covers/external_image.html, templates/covers/saved.html, templates/reading_goals/reading_goal_form.html, templates/books/add.html, templates/books/edit.html, templates/books/edit/edition.html, templates/type/list/view_body.html, templates/type/tag/form.html, templates/lib/exports.html, templates/merge_request_table/table_row.html, templates/account/create.html.

• openlibrary/tests/test_templates.py already exists but only validates template syntax (via web.template.Template) — it does not check security attributes. The proposed test_noopener_noreferrer test would be a new addition to this file.

• Several of the flagged links point to internal OL paths (e.g., /help/faq/reading-log#lists, /authors/OL23919A, /works/OL262757W). These arguably should not use target="_blank" at all, independent of the rel fix.

• No prior issue or PR was found specifically targeting this vulnerability.

---

Issue Assessment

Open questions

• Several flagged links point to same-origin OL paths — should the fix also remove target="_blank" from those links, or only add rel="noopener noreferrer"?
• noreferrer strips the Referer header. For links to blog.openlibrary.org and archive.org, this may affect referral analytics. Is rel="noopener" alone sufficient per project policy, or is noreferrer required?
• templates/work_search.html links directly to the Solr select URL with target="_blank" — is that intentional (debug tooling)?

Action items

• Clarify whether internal-path links should have target="_blank" removed vs. just receiving a rel attribute
• Confirm whether noreferrer is required or noopener alone is sufficient for links to IA/OL-adjacent domains
• Add a complete checklist of the 33 affected file/line locations to this issue for contributor tracking

Suggested breakdown

• Add rel="noopener noreferrer" to all external links with target="_blank" across templates and macros (can be split by directory: macros/, templates/books/, templates/account/, etc.) — each sub-directory pass is a candidate Good First Issue once triage is complete
• Separately evaluate and clean up same-origin links that use target="_blank" without clear justification
• Add test_noopener_noreferrer to openlibrary/tests/test_templates.py to prevent regressions — Good First Issue candidate (well-scoped, self-contained, ≤ 1 hour)

---

Full triage checklist (maintainers / Pam)

• Triage — correct labels applied or removed: Needs: Breakdown, Needs: Investigation, Needs: Design, Needs: Staff Decision, Needs: Staff / Admin, Good First Issue, Blocked, Blocker
• Problem / opportunity — problem is clear, audience identified, actionable
• Scope — issue is well-scoped; single class of security fix across templates
• Justification — reasoning present; urgency not stated (risk is partially mitigated by modern browsers but real for older ones)
• Success & testing criteria — test command provided but acceptance criteria for internal-link handling not defined
• Proposal & breakdown — fix approach clear but no complete checklist of all 33 instances
• If bug: environment & repro steps — repro path clear (browser inspector on /account/create); browser/OS context not filled in but not required for this type of issue
• Risks, concerns, open questions — surfaced above; no Blocker applied (existing vulnerability, not introduced by proposal)
• Pam context — grep of local codebase; test file inspected; no duplicate issue found
• References — screenshot and code examples present

Note

This comment was automatically generated by Pam, Open Library's Project AI Manager, on behalf of @mekarpeles. Pam is designed to provide status visibility, perform basic project management functions and relevant codebase research, and provide actionable feedback so contributors aren't left waiting.

[mekarpeles]

@akramcodez thank you, pinging @jimchamp for assessment and triage!

[akramcodez]

Hi @jimchamp, I’d like to work on this could you please assign it to me?

[jimchamp]

What is this test that you used to find this information? Is there really a risk of Internet Archive attacking its own patrons, as your terms of service example suggests?

I'm less concerned about links that are in our templates, and more concerned with unvetted links added by users uploading content.

Also, my understanding is that modern browsers add rel="noopener" by default when `target="_blank", which should largely mitigate this risk.

You can work on this if you want to. Afterwards, should you want to work on another issue, please consider one of our 750+ other issues (each of which have affected patrons in some way).