Security & Rate Limiting

CourseWeave has two browser-facing endpoints that accept user input:

• Report Issue / Session Reflection — student-facing, posts to a Cloudflare Worker → GitHub Issues
• Content Creator (Alt+C) — teacher-facing, posts to a Cloudflare Worker → GitHub Issues

Both sit behind a layered defence: client-side rate limiting, a honeypot field, and a server-side backstop at the Cloudflare Worker.

---

Why not IP-based rate limiting?

IP-based rate limiting is the default in most tutorials, but it breaks in a university context: all students on campus or in a dormitory typically share one or a few NAT’d IP addresses. One student submitting ten feedback items would block the entire cohort for an hour.

Cloudflare Turnstile / reCAPTCHA were also considered and rejected:

• reCAPTCHA is blocked in China.
• Cloudflare Turnstile’s challenge endpoint (challenges.cloudflare.com) is reachable from mainland China in most cases but is not guaranteed reliable across all campus networks.
• A CAPTCHA that silently fails blocks the form entirely. Students behind university proxies or VPNs (common in China) are the most likely to trigger false positives.

For a course feedback form, the threat model does not justify that failure mode.

---

Client-side rate limiting (localStorage)

Rate limits are enforced in the browser using localStorage, keyed per device. Timestamps older than 24 hours are pruned on each check so storage never accumulates.

Form	Key	Limit
Report Issue (general feedback)	courseweave_rl	10/hour, 30/day
Session Reflection (CIQ)	courseweave_rl (same log, category: 'reflection')	2/day
Content Creator	courseweave_cc_rl	20/hour, 50/day

When a limit is exceeded:

• Report Issue — the form switches to the error panel with a friendly explanation.
• Content Creator — a toast notification appears in the top-right corner.

The limits are defined as named constants at the top of each component’s <script> block, making them straightforward to adjust:

ReportIssue.astro

const RL_LIMIT_HOUR = 10;
const RL_LIMIT_DAY  = 30;
const RL_LIMIT_CIQ_DAY = 2;

// ContentCreatorBar.astro
const CC_RL_LIMIT_HOUR = 20;
const CC_RL_LIMIT_DAY  = 50;

---

Honeypot fields

Both forms include a visually hidden input that is never filled by a real user but will be filled by simple bots that blindly populate all fields. If the honeypot field is non-empty on submission, the request is silently dropped (for bots) or a fake success is shown (for the Report Issue form, to avoid tipping off scrapers).

<!-- Hidden from real users, visible to bots -->
<input type="text" name="website" tabindex="-1"
  style="position: absolute; left: -9999px;" autocomplete="off" aria-hidden="true" />

---

Cloudflare Worker (server-side backstop)

The client-side limits are the primary guard. The Cloudflare Worker provides a high-threshold backstop against scripted abuse that bypasses the browser entirely (e.g., direct curl requests to the worker URL).

Recommended Worker configuration:

Setting	Value	Reason
IP rate limit	200–500 requests/hour	High enough that a legitimate classroom session never hits it; low enough to block sustained scripted attacks
Allowed origins	Your site’s domain only	Rejects requests not originating from the course site
Secret header (optional)	Static token in config.ts	Cheaply blocks direct API abuse without user friction

The Worker rate limit is intentionally set high because the client-side limits handle the normal case. Lowering the Worker limit risks re-introducing the shared-IP problem the client-side approach was designed to avoid.

---

Summary

Real user  →  honeypot check  →  localStorage rate limit  →  Cloudflare Worker  →  GitHub Issues API
Bot        →  honeypot check  →  silently dropped / fake success
Scripter   →  (bypasses browser)  →  Cloudflare Worker IP limit  →  blocked

No CAPTCHA, no IP blocking of shared addresses, no dependency on services blocked in China.