Area
Authentication
What happened?
A security audit of our backend routing has revealed multiple critical API endpoints that currently lack authentication gatekeeping. Unauthenticated users can access these routes directly, posing severe risks including message spoofing, unauthorized data exposure (chat history leaks), and unauthorized modification of server structures (channels/categories/invites).
While a robust authToken middleware exists within auth.js, it is not universally applied. This issue tracks the immediate containment of these security gaps by attaching the middleware to the completely unprotected routes.
Affected Routes & Risk Assessment
chat.js — POST /store_message
Risk: 🔴 Critical. Sender identity is currently accepted via req.body with no token verification, allowing message impersonation.
chat.js — POST /get_messages
Risk: 🔴 Critical. No auth check; anyone can read any channel's historical chat logs.
chat.js — POST /toggle_server_message_pin
Risk: 🟠 Medium. Uses inline token parsing but lacks a strict middleware gate.
servers.js — POST /add_new_channel
Risk: 🔴 High. Allows unauthenticated structural modification of any server.
servers.js — POST /add_new_category
Risk: 🔴 High. Allows unauthenticated structural modification of any server.
invites.js — POST /create_invite_link
Risk: 🔴 High. Unauthorized creation of server invites.
invites.js — POST /invite_link_info
Risk: 🟡 Low/Medium. Information leak revealing server metadata.
invites.js — POST /accept_invite
Risk: 🔴 High. Allows anyone to join any server without verification.
- Proposed Changes
- chat.js
Import the authToken middleware.
Secure POST /store_message. Ensure the sender's authenticated identity (req.user) acts as the baseline validation rather than purely trusting the incoming payload data in req.body.
Secure POST /get_messages and POST /toggle_server_message_pin.
- servers.js
Import the authToken middleware.
Apply authToken to POST /add_new_channel and POST /add_new_category.
- invites.js
Import the authToken middleware.
Apply authToken to POST /create_invite_link, POST /invite_link_info, and POST /accept_invite.
2.The Proposed Solution
To solve this, we applied the pre-existing authToken middleware to guard the unprotected endpoints.
When an API request is made to any of these secured endpoints:
The server intercepts the request before it reaches the main handler.
It looks for a token inside the x-auth-token header.
If no token is provided, or if the token is invalid/expired, the server immediately halts the request and returns a 401 Unauthorized status code.
If the token is valid, it decodes the user's account details, attaches them to the request context, and allows the request to execute safely.
- Detailed Changes by Module
Chat Module
Sticker/Message Storage: Secured the endpoint that saves incoming chat messages. Now, the sender's token must be verified, preventing malicious users from spoofing messages from other members.
Retrieve Messages: Secured the endpoint that fetches channel histories. Now, only users who present a valid authentication token can download and read the messages.
Pin Message: Secured the message pinning toggle. Now, the request must go through the authentication check first.
Server Management Module
Create Channel: Secured the endpoint that adds new text/voice channels to a server. Now, only authenticated users can attempt to add channels.
Create Category: Secured the endpoint that adds structural categories. This prevents unauthorized users from altering server layouts.
Invitation Module
Create Invite Link: Secured invite link generation. Only authenticated members can create invites.
Invite Information Lookup: Secured the endpoint that extracts server metadata from an invite code. This stops bots or unauthorized users from scraping server names and assets.
Accept Invite: Secured the join-server action. Only verified, logged-in accounts are permitted to join servers using an invite code.
- Verification
The authentication system was validated using the backend's internal unit tests to ensure that the token verification logic behaves correctly and does not break existing features.
To verify manually:
Sending a request to these endpoints without the header yields a 401 Unauthorized response.
Sending a request with a valid token allows the action to complete normally.
Steps to reproduce
- Open the backend codebase and navigate to the routing files: server/routes/chat.js, server/routes/servers.js, and server/routes/invites.js.
- Inspect the HTTP POST route definitions (e.g., router.post('/get_messages', ...)).
- Observe that the authToken middleware is entirely absent from the middleware chain on these critical endpoints.
Expected behavior
All endpoints handling sensitive user data, historical messages, or server structural modifications (channels, categories, invites) must be gated by the authToken middleware to ensure requests originate from a verified, authenticated session.
Actual behavior
The endpoints are exposed publicly with zero authentication validation, allowing anyone to fetch data, manipulate server structures, or spoof sender identities by passing unverified payloads in req.body.
App surface
Login
Local environment
No response
Console, network, or server logs
Screenshots or recordings
No response
Before submitting
Area
Authentication
What happened?
A security audit of our backend routing has revealed multiple critical API endpoints that currently lack authentication gatekeeping. Unauthenticated users can access these routes directly, posing severe risks including message spoofing, unauthorized data exposure (chat history leaks), and unauthorized modification of server structures (channels/categories/invites).
While a robust authToken middleware exists within auth.js, it is not universally applied. This issue tracks the immediate containment of these security gaps by attaching the middleware to the completely unprotected routes.
Affected Routes & Risk Assessment
chat.js — POST /store_message
Risk: 🔴 Critical. Sender identity is currently accepted via req.body with no token verification, allowing message impersonation.
chat.js — POST /get_messages
Risk: 🔴 Critical. No auth check; anyone can read any channel's historical chat logs.
chat.js — POST /toggle_server_message_pin
Risk: 🟠 Medium. Uses inline token parsing but lacks a strict middleware gate.
servers.js — POST /add_new_channel
Risk: 🔴 High. Allows unauthenticated structural modification of any server.
servers.js — POST /add_new_category
Risk: 🔴 High. Allows unauthenticated structural modification of any server.
invites.js — POST /create_invite_link
Risk: 🔴 High. Unauthorized creation of server invites.
invites.js — POST /invite_link_info
Risk: 🟡 Low/Medium. Information leak revealing server metadata.
invites.js — POST /accept_invite
Risk: 🔴 High. Allows anyone to join any server without verification.
Import the authToken middleware.
Secure POST /store_message. Ensure the sender's authenticated identity (req.user) acts as the baseline validation rather than purely trusting the incoming payload data in req.body.
Secure POST /get_messages and POST /toggle_server_message_pin.
Import the authToken middleware.
Apply authToken to POST /add_new_channel and POST /add_new_category.
Import the authToken middleware.
Apply authToken to POST /create_invite_link, POST /invite_link_info, and POST /accept_invite.
2.The Proposed Solution
To solve this, we applied the pre-existing authToken middleware to guard the unprotected endpoints.
When an API request is made to any of these secured endpoints:
The server intercepts the request before it reaches the main handler.
It looks for a token inside the x-auth-token header.
If no token is provided, or if the token is invalid/expired, the server immediately halts the request and returns a 401 Unauthorized status code.
If the token is valid, it decodes the user's account details, attaches them to the request context, and allows the request to execute safely.
Chat Module
Sticker/Message Storage: Secured the endpoint that saves incoming chat messages. Now, the sender's token must be verified, preventing malicious users from spoofing messages from other members.
Retrieve Messages: Secured the endpoint that fetches channel histories. Now, only users who present a valid authentication token can download and read the messages.
Pin Message: Secured the message pinning toggle. Now, the request must go through the authentication check first.
Server Management Module
Create Channel: Secured the endpoint that adds new text/voice channels to a server. Now, only authenticated users can attempt to add channels.
Create Category: Secured the endpoint that adds structural categories. This prevents unauthorized users from altering server layouts.
Invitation Module
Create Invite Link: Secured invite link generation. Only authenticated members can create invites.
Invite Information Lookup: Secured the endpoint that extracts server metadata from an invite code. This stops bots or unauthorized users from scraping server names and assets.
Accept Invite: Secured the join-server action. Only verified, logged-in accounts are permitted to join servers using an invite code.
The authentication system was validated using the backend's internal unit tests to ensure that the token verification logic behaves correctly and does not break existing features.
To verify manually:
Sending a request to these endpoints without the header yields a 401 Unauthorized response.
Sending a request with a valid token allows the action to complete normally.
Steps to reproduce
Expected behavior
All endpoints handling sensitive user data, historical messages, or server structural modifications (channels, categories, invites) must be gated by the authToken middleware to ensure requests originate from a verified, authenticated session.
Actual behavior
The endpoints are exposed publicly with zero authentication validation, allowing anyone to fetch data, manipulate server structures, or spoof sender identities by passing unverified payloads in req.body.
App surface
Login
Local environment
No response
Console, network, or server logs
Screenshots or recordings
No response
Before submitting