BC-10757 - content authorization

[virgilchiriac]

Description

Links to Tickets or other pull requests

BC-10757

hpi-schul-cloud/schulcloud-server#5943

Changes

Data Security

Deployment

New Repos, NPM packages or vendor scripts

Screenshots of UI changes

Approval for review

• QA: In addition to review, the code has been manually tested (if manual testing is possible)
• All points were discussed with the ticket creator, support-team or product owner. The code upholds all quality guidelines from the PR-template.
• DEV: Every new component is implemented having accessibility in mind (e.g. aria-label, role property)

Notice: Please remove the WIP label if the PR is ready to review, otherwise nobody will review it.

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

To address this, implement rate limiting for the router defined in this file using a popular, well-supported middleware such as express-rate-limit. This should be applied just after authentication and before (or with) preventCourseLocked to ensure excessive requests to these endpoints do not overwhelm the system.

Specifically:

• Import express-rate-limit at the top of the file.
• Create a rate limiter instance (configurable, e.g., 100 requests per 15 minutes per IP).
• Insert router.use(limiter); between the authentication middleware and the rest (or strictly before preventCourseLocked).
• No changes are needed to route handlers or existing middleware ordering/functionality.

---

To address the missing rate limiting, we should add a rate-limiting middleware to this router (the Express router instance in controllers/courses.js). The standard solution in Express is the express-rate-limit package, which should be required and configured. The rate limiter middleware should be added as soon as possible after the authentication and authorization middleware (authChecker and preventCourseLocked).
This can be accomplished by:

1. Adding a require('express-rate-limit') at the top.
2. Creating a rate limiter instance with settings appropriate for the sensitivity of these routes (e.g., a reasonable number of requests per window per user).
3. Applying the limiter with router.use(limiter); just after authChecker and preventCourseLocked middlewares.

This change will ensure requests to secured course routes are subject to rate limiting, and protect against brute-force/DoS attacks.

To fix the issue, a rate limiting middleware should be applied before (router.use) the expensive or sensitive route middleware, such as preventCourseLocked. In Express, the standard is to use the widely adopted express-rate-limit package. The most sensible approach is to import express-rate-limit, configure a reasonable rate limiter (e.g., 100 requests per 15 minutes per IP), and apply it before the code that currently calls preventCourseLocked. This approach globally limits all endpoints covered by this router, requiring only minimal code changes and no alterations in existing behavior, except defending against DoS. The following changes are needed:

• Import express-rate-limit.
• Add the rate limiter middleware before preventCourseLocked.

---

The recommended fix is to add rate limiting middleware to the router, as early as possible (before other resource-intensive or authorization middlewares). The express-rate-limit package is a widely used solution for Express apps.

• Add a rate limiter instance, for example:

  const rateLimit = require('express-rate-limit');
  const limiter = rateLimit({
    windowMs: 15 * 60 * 1000, // 15 minutes
    max: 100, // limit each IP to 100 requests per windowMs
  });

• Apply the limiter to the router (e.g., router.use(limiter);) before resource-intensive or authorization middlewares.
• Update the imports section at the top of the file to include express-rate-limit.

This conservatively protects all routes within this controller against DOS attacks, without interfering with existing functionality.

---

To address the detected vulnerability, rate-limiting should be added to the router so that potentially expensive endpoint access is restricted. The best way is to use a middleware such as express-rate-limit, as recommended in CodeQL’s guidance. Specifically, create a rate-limiter middleware instance (e.g., allowing 100 requests per 15 minutes per IP), and apply it before the authorization and preventCourseLocked middleware using router.use. This means inserting the necessary import, creating the limiter, and placing router.use(limiter) at the correct point so that all routes handled by this router are protected. No other code needs to be changed, and existing functionality will remain untouched.

The following regions/lines in controllers/topics.js need edits:

• Add an import for express-rate-limit.
• Add the rate-limiter configuration.
• Use router.use(limiter) before security and expensive handlers.

---