Security Regression Testing

Write tests that specifically target known vulnerability vectors like SQLi or XSS.

In this lesson, you will learn how to weaponize your test suite to prevent the re-introduction of patched vulnerabilities by writing explicit security regression tests.

When you discover a vulnerability—like a SQL injection (SQLi) or Stored Cross-Site Scripting (XSS)—fixing it is only half the battle. Without a dedicated test, a future refactor might inadvertently strip away your input sanitization or restore a vulnerable database query. Security regression testing involves treating a discovered CVE or bug as a mandatory test case that must never fail again.

Designing Targeted Security Tests

Instead of testing for general correctness, you must create "negative tests" that attempt to pass malicious payloads into your application. If your application previously suffered from a SQLi in a login route, your regression test should attempt to inject common SQL syntax to verify the fix holds.

Consider this example using a standard testing framework like supertest:

// Security regression test for a previously patched SQLi vulnerability
it('should reject SQL injection payloads in the username field', async () => {
  const maliciousInput = "' OR '1'='1";
  
  const response = await request(app)
    .post('/api/login')
    .send({ username: maliciousInput, password: 'password123' });

  // We expect a 400 or 401, NOT a 200 or 500 error
  expect(response.status).not.toBe(200);
  expect(response.body.message).toMatch(/invalid/i);
});

Why This Matters

For XSS, your test should verify that HTML characters are correctly escaped by the template engine or serializer. If your User profile page was vulnerable, write a test that posts a payload like <script>alert('xss')</script> and asserts that the rendered response contains the escaped entities (e.g., <script>) rather than the raw executable tag.

By keeping these tests in your permanent suite, you create a "security moat." If a developer accidentally updates a library or removes a validation function, the build will break immediately, alerting the team that a previous security guarantee has been compromised before the code ever reaches production.

Key Takeaway: Never consider a vulnerability fixed until you have written a regression test that fails against the vulnerable code and passes against the patched version.