Modsecurity: Book Cover 403 Forbidden

[Marla-1913]

Problem

As requested by @mekarpeles at #12718, I'm creating a new issue. More than once (most recently today), I've gotten a "Book Cover 403 Forbidden" message when I tried to upload book covers from my computer to the following editions:

https://openlibrary.org/books/OL62382445M/Addicted_to_Anxiety
https://openlibrary.org/books/OL33666561M/Ten_Times_Happier

Reproducing the bug

1. Go to edition OL62382445M [ISBN 9781250439970] or OL33666561M (ISBN 9780008378240);
2. Click "Edit";
3. Click "Add Cover Image";
4. Click "Choose File";
5. Navigate to and select the appropriate cover;
6. Click "Upload."

• Expected behavior: The cover should have been uploaded to the edition.
• Actual behavior: Received a "Book Cover 403: Forbidden" message (see screenshots above).

Context

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

Breakdown

Implementation Details (for maintainers)

Requirements Checklist

• [ ]

Related files

Stakeholders

---

Instructions for Contributors

• Please run these commands to ensure your repository is up to date before creating a new branch to work on this issue and each time after pushing code to Github, because the pre-commit bot may add commits to your PRs upstream.

[openlibrary-bot]

Thank you @Marla-1913 for submitting this issue!

Warning

This issue requires access to internal infrastructure, production systems, or institutional knowledge unavailable to community contributors. It can only be resolved by a maintainer or staff member.

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

• Triage — maintainers will add Priority: * and Lead: @*
• Needs: Investigation — root cause or approach unknown; research required first
• Needs: Staff / Internal — requires production access or institutional knowledge

---

Context

• add_cover.POST() in covers.py#L61-L68 only raises an application-level 403 (web.forbidden) when the authenticated user is flagged read-only. Nothing else in this file returns a 403, which points away from an app-layer cause and toward the WAF/nginx layer sitting in front of the app — consistent with the ModSecurity pattern already tracked elsewhere (see below). The same upload code path is shared by edition, work, and author cover routes (add_cover, add_work_cover, add_photo).
• Likely related/duplicate: modsec: Can't upload cover art #13232 "modsec: Can't upload cover art" (open) — same symptom (cover upload fails on prod). A contributor there traced the root cause to ModSecurity's SecRequestBodyNoFilesLimit (~1MB default), which blocks file uploads over that size with an HTTP 460 before the request reaches the app. This issue reports an HTTP 403 rather than 460, so it may be the same WAF layer tripping a different rule, rather than the exact same defect — worth confirming either way.
• Modsecurity: 403 Forbidden #12718 "Modsecurity: 403 Forbidden" (closed 2026-07-28 as completed) was the general-purpose ModSecurity false-positive tracking issue. It was closed specifically so that new false positives would be filed as individual, narrowly-scoped issues going forward — this issue is exactly that pattern, and cover uploads were called out there as a known problem area.
• ModSecurity: Automated Daily Review & Rule-Update Pipeline #13225 "ModSecurity: Automated Daily Review & Rule-Update Pipeline" (open) is the active epic for systematically catching and fixing these WAF false positives.

---

Issue Assessment

Open questions

• What is the file size of the covers being uploaded to these two editions? (Determines whether this is the same SecRequestBodyNoFilesLimit/460 issue as modsec: Can't upload cover art #13232, or a distinct rule producing a genuine 403.)
• Does the browser's Network tab show the 403 response coming back with an nginx-style body (WAF/server layer) or an OpenLibrary-rendered page (app layer)? This is the fastest way to confirm the layer at fault.
• Is the failure consistent on every attempt for these two editions, or intermittent (as with most reports in Modsecurity: 403 Forbidden #12718)?

Action items

• Determine whether the app-level read-only check could be the cause (Answer: unlikely — that check only fires for accounts flagged read-only, which wouldn't explain a logged-in editor failing on arbitrary editions; the pattern matches the WAF-layer issue tracked in modsec: Can't upload cover art #13232/Modsecurity: 403 Forbidden #12718 instead).

---

🔔 Stakeholders
@jimchamp — Lead on both #13232 (near-duplicate cover-upload ModSecurity report) and #13225 (the ModSecurity automated review pipeline epic).

---

Full triage checklist

• Triage — correct labels applied or removed
• Problem / opportunity — problem is clear, audience identified, actionable
• Scope — issue is well-scoped; does not try to do too many things
• Justification — reasoning and impact stated; sufficient for leads to prioritize
• Success & testing criteria — defines what "done" looks like, verifiable by a contributor
• Proposal & breakdown — concrete plan present; checklist actionable for a contributor
• If bug: environment & repro steps — browser, version, local vs prod; steps to reproduce
• Risks, concerns, open questions — identified and surfaced
• Richy context — relevant code, commits, PRs reviewed; no duplicate found
• References — screenshots, designs, docs, and links present where needed

---

Note

This comment was automatically generated by Richy, Open Library's issue enrichment assistant, on behalf of @mekarpeles. This is NOT a sign-off. This issue needs lead review before work begins.

[CipherZ3r0]

I tried reproducing this issue on the affected edition and was able to successfully upload the book cover for edition OL62382445M [ISBN 9781250439970] and OL33666561M [ISBN 9780008378240] already had successfully uploaded book cover

However, I repeatedly encountered 503 Service Unavailable errors when:

• Trying to edit the cover again after the upload.
• Simply accessing the book page normally.

The server was also noticeably slow to respond during these attempts.

I tried accessing the edition again after some time, and the page was working normally. This makes me suspect that the 503 Service Unavailable responses may be related to temporary server/backend availability or resource issues rather than the specific edition itself.

The cover upload itself eventually succeeded, so I was unable to reproduce the original 403 Forbidden on the upload. However, I was able to reproduce the intermittent 503 responses when accessing/editing the edition.

I've attached screenshots from my device showing the 503 Service Unavailable responses.

---