Potential fix for code scanning alert no. 366: Missing rate limiting

[mmeerrkkaa]

Potential fix for https://github.com/blockmineJS/blockmine/security/code-scanning/366

To fix this cleanly without changing existing functionality, attach a rate-limiting middleware to the /status route, just like the other routes in this file.

Best single change in this snippet:

• Update router.get('/status', ...) to include checkLimiter (already defined and suitable for read/check-style operations).
• No new imports or dependencies are required because express-rate-limit is already used and both limiters are already defined.

Specific edit region:

• File: backend/src/api/routes/panelUpdate.js
• Lines/region: Route definition around current line 35 (/status endpoint)

This addresses all alert variants at the same location by ensuring the authenticated /status handler is rate-limited.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

Summary by Sourcery

Protect panel update endpoints with consistent rate-limiting middleware while preserving their existing behavior.

Bug Fixes:

• Add rate limiting to the panel update status endpoint to address the missing rate-limiting code scanning alert.

Enhancements:

• Standardize middleware ordering across panel update check, status, and apply routes.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 58 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 6167aa60-effd-4fdd-ac00-11bcafa72f77

📥 Commits

Reviewing files that changed from the base of the PR and between 04b9f78 and fb93ae8.

📒 Files selected for processing (1)

• backend/src/api/routes/panelUpdate.js

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

The panel update routes now consistently invoke their existing rate limiters before authentication, including the previously unprotected /status endpoint, addressing the missing rate-limiting alert without adding dependencies or changing handler behavior.

Flow diagram for rate-limited panel update routes

flowchart TD
    Check[GET /check] --> CheckLimiter[checkLimiter]
    Status[GET /status] --> StatusLimiter[checkLimiter]
    Apply[POST /apply] --> ApplyLimiter[applyLimiter]
    CheckLimiter --> CheckAuth[authenticateUniversal]
    StatusLimiter --> StatusAuth[authenticateUniversal]
    ApplyLimiter --> ApplyAuth[authenticateUniversal]
    CheckAuth --> CheckHandler[PanelUpdateService.checkForUpdate]
    StatusAuth --> StatusHandler[PanelUpdateService.getProgress]
    ApplyAuth --> Authorize[authorize]
    Authorize --> ApplyHandler[PanelUpdateService.applyUpdate]

Loading

File-Level Changes

Change	Details	Files
Add consistent rate limiting and middleware ordering to panel update routes.	Apply the existing check limiter before authentication on the update check endpoint. Rate-limit the status endpoint using the existing check limiter before authentication. Move the existing apply limiter before authentication and authorization on the update application endpoint.	backend/src/api/routes/panelUpdate.js

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 2 issues

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="backend/src/api/routes/panelUpdate.js" line_range="24" />
<code_context>
 });

-router.get('/check', authenticateUniversal, checkLimiter, async (req, res) => {
+router.get('/check', checkLimiter, authenticateUniversal, async (req, res) => {
     try {
         const fresh = req.query.fresh === '1' || req.query.fresh === 'true';
</code_context>
<issue_to_address>
**Unauthenticated traffic blocks panel users**

When unauthenticated requests share a client IP with an authorized user and exhaust a route quota, `checkLimiter` and `applyLimiter` run before authentication or authorization and count by IP, so unauthenticated requests consume the authorized caller’s quota; subsequent `/check`, `/status`, or `/apply` requests receive 429 responses.

Run each authenticated-user limiter after authentication (and authorization for `/apply`), or keep pre-authentication IP limiting in a separate bucket.

Also at `backend/src/api/routes/panelUpdate.js:25`, `backend/src/api/routes/panelUpdate.js:35-36`, `backend/src/api/routes/panelUpdate.js:39-40`.
</issue_to_address>

### Comment 2
<location path="backend/src/api/routes/panelUpdate.js" line_range="35" />
<code_context>
 });

-router.get('/status', authenticateUniversal, (req, res) => {
+router.get('/status', checkLimiter, authenticateUniversal, (req, res) => {
     res.json(PanelUpdateService.getProgress());
 });
</code_context>
<issue_to_address>
**Update progress stops refreshing**

When an update remains active until the shared 40-request quota is exhausted, including when earlier checks used some of the quota, `checkLimiter` rejects `/status` polls with 429, and `pollStatus` ignores non-OK responses, so the dialog’s displayed progress stays stale while the update continues.

Give `/status` polling a separate, suitably sized limit or exempt it from the `/check` limiter.

Also at `backend/src/api/routes/panelUpdate.js:36`.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[sourcery-ai]

🟡 Medium · Unauthenticated traffic blocks panel users

When unauthenticated requests share a client IP with an authorized user and exhaust a route quota, checkLimiter and applyLimiter run before authentication or authorization and count by IP, so unauthenticated requests consume the authorized caller’s quota; subsequent /check, /status, or /apply requests receive 429 responses.

Run each authenticated-user limiter after authentication (and authorization for /apply), or keep pre-authentication IP limiting in a separate bucket.

Also at backend/src/api/routes/panelUpdate.js:25, backend/src/api/routes/panelUpdate.js:35-36, backend/src/api/routes/panelUpdate.js:39-40.

Prompt for AI agents

In `backend/src/api/routes/panelUpdate.js` at line 24:

**Unauthenticated traffic blocks panel users**

When unauthenticated requests share a client IP with an authorized user and exhaust a route quota, `checkLimiter` and `applyLimiter` run before authentication or authorization and count by IP, so unauthenticated requests consume the authorized caller’s quota; subsequent `/check`, `/status`, or `/apply` requests receive 429 responses.

Run each authenticated-user limiter after authentication (and authorization for `/apply`), or keep pre-authentication IP limiting in a separate bucket.

Also at `backend/src/api/routes/panelUpdate.js:25`, `backend/src/api/routes/panelUpdate.js:35-36`, `backend/src/api/routes/panelUpdate.js:39-40`.

[sourcery-ai]

🟠 High · Update progress stops refreshing

When an update remains active until the shared 40-request quota is exhausted, including when earlier checks used some of the quota, checkLimiter rejects /status polls with 429, and pollStatus ignores non-OK responses, so the dialog’s displayed progress stays stale while the update continues.

Give /status polling a separate, suitably sized limit or exempt it from the /check limiter.

Also at backend/src/api/routes/panelUpdate.js:36.

Prompt for AI agents

In `backend/src/api/routes/panelUpdate.js` at line 35:

**Update progress stops refreshing**

When an update remains active until the shared 40-request quota is exhausted, including when earlier checks used some of the quota, `checkLimiter` rejects `/status` polls with 429, and `pollStatus` ignores non-OK responses, so the dialog’s displayed progress stays stale while the update continues.

Give `/status` polling a separate, suitably sized limit or exempt it from the `/check` limiter.

Also at `backend/src/api/routes/panelUpdate.js:36`.