fixes:
  - id: 1
    explanation: "Trying to prevent any injection attacks with a custom-built blocklist mechanism is doomed to fail. It might work for some simpler attack payloads but an attacker with time and skills can likely bypass it at some point."
  - id: 2
    explanation: 'Using the built-in binding (or replacement) mechanism of Sequelize is equivalent to creating a Prepared Statement. This prevents tampering with the query syntax through malicious user input as it is "set in stone" before the criteria parameter is inserted.'
  - id: 3
    explanation: 'This fix unfortunately goes only half the way to using the replacement mechanism of Sequelize. Such a Prepared Statement still concatenated from user input, is still wide open for SQL Injection attacks.'
  - id: 4
    explanation: 'Turning off the "plain" flag will let Sequelize return all matching rows instead of just the first one. This neither makes sense from a functional point of view in a login function, not could it prevent SQL Injection attacks.'
hints:
  - "Try to identify any variables in the code that might contain arbitrary user input."
  - "Follow the user input through the function call and try to spot places where it might be abused for malicious purposes."
  - "Can you spot a place where a SQL query is being cobbled together in an unsafe way?"
