HIGH auth bypassadonisjsmysql

Auth Bypass in Adonisjs with Mysql

Auth Bypass in Adonisjs with Mysql — how this specific combination creates or exposes the vulnerability

AdonisJS is a Node.js web framework that often uses MySQL as the default relational database. When authentication logic relies on raw or loosely validated database queries, an attacker can exploit subtle query construction issues to bypass intended access controls. A common pattern is building a WHERE clause by directly concatenating user input into a string without parameterization or proper schema awareness. For example, an attacker may supply ' OR 1=1 -- as a username or password, which alters the SQL logic and can return a valid user row without knowing the correct credentials. Because MySQL is lenient with type coercion and comment syntax, such inputs may be interpreted as valid SQL rather than causing an error, allowing authentication to succeed unexpectedly.

In AdonisJS, developers sometimes use Lucid ORM models or raw queries via the Database module. If they construct conditions by injecting request body values directly into where clauses, they may inadvertently expose authentication bypass paths. Consider a login routine that builds a query like User.query().where('email', email).where('password', password). If the surrounding logic incorrectly treats a truthy query result as successful authentication without verifying password hashes, or if the query is malformed due to dynamic column names, the check can be trivially bypassed. Additionally, MySQL-specific behaviors such as case-insensitive collation or whitespace handling can cause string comparisons to match unexpectedly, further weakening the intended guardrails.

Another vector involves permission checks performed in application code after a user is fetched. If the developer assumes that the user row returned from MySQL is authoritative and does not re-validate scopes or tenant identifiers, an attacker who can manipulate the query (e.g., via IDOR or subtle injection) may gain access to resources they should not see. The combination of AdonisJS abstractions and MySQL’s flexible query semantics can obscure these gaps, especially when developers rely on implicit defaults rather than explicit constraints. This is particularly risky when using dynamic column references or raw fragments that do not enforce strict schema boundaries.

Mysql-Specific Remediation in Adonisjs — concrete code fixes

To mitigate authentication bypass risks, always use parameterized queries or the query builder’s binding mechanisms when interacting with MySQL in AdonisJS. Avoid string interpolation for SQL fragments. For example, instead of concatenating values into raw SQL, use named bindings or the where clause safely. Below is a secure login example using AdonisJS Lucid model with proper parameterization:

import User from 'App/Models/User'
import { schema } from '@ioc:Adonis/Core/Validator'

export async function login({ request, auth }) {
  const email = request.input('email')
  const password = request.input('password')

  const user = await User.query()
    .where('email', email)
    .preload('role')
    .first()

  if (!user || !(await verifyPassword(password, user.password))) {
    throw new Error('Invalid credentials')
  }

  await auth.login(user)
  return user
}

This ensures that the email comparison is treated as a literal value, preventing malicious SQL from altering the WHERE clause. For additional safety when using raw queries, bind parameters explicitly:

import Database from '@ioc:Adonis/Lucid/Database'

const result = await Database.from('users')
  .where('email', '=', email)
  .andWhere('deleted_at', null)
  .limit(1)

When dynamic column or table names are unavoidable, validate them against a strict allowlist before inclusion, and never inject them directly into raw SQL strings. For MySQL-specific nuances, enforce UTF8MB4 encoding and explicit collation to reduce unexpected matching due to case or accent sensitivity. Also, ensure that password verification uses a strong, adaptive hash (e.g., bcrypt) and is always executed server-side, independent of database-side transformations.

Finally, complement these code-level fixes with runtime security checks. middleBrick can scan your API endpoints, including those built with AdonisJS and backed by MySQL, to detect authentication bypass risks and other misconfigurations. By integrating the CLI (middlebrick scan <url>) or the GitHub Action into your CI/CD pipeline, you can automatically fail builds when security scores drop below your chosen threshold, ensuring that issues are caught before deployment.

Related CWEs: authentication

CWE IDNameSeverity
CWE-287Improper Authentication CRITICAL
CWE-306Missing Authentication for Critical Function CRITICAL
CWE-307Brute Force HIGH
CWE-308Single-Factor Authentication MEDIUM
CWE-309Use of Password System for Primary Authentication MEDIUM
CWE-347Improper Verification of Cryptographic Signature HIGH
CWE-384Session Fixation HIGH
CWE-521Weak Password Requirements MEDIUM
CWE-613Insufficient Session Expiration MEDIUM
CWE-640Weak Password Recovery HIGH

Frequently Asked Questions

Can middleBrick detect authentication bypass issues in AdonisJS APIs backed by MySQL?
Yes, middleBrick scans unauthenticated attack surfaces and includes checks such as Authentication and BOLA/IDOR, which can identify indicators of authentication bypass risks in APIs regardless of the backend framework or database.
How can I remediate findings reported by middleBrick for my AdonisJS + MySQL API?
Use the findings and remediation guidance provided in the middleBrick report to review your query construction, input validation, and permission checks. Apply secure coding practices such as parameterized queries, strict input validation, and server-side password verification, then re-scan to confirm improvements.