Answer.

Background of the question

With the rise in cyberattacks, the emphasis on security testing has intensified. Even for manual testers, it's important to be able to identify standard vulnerabilities.

Problem

Often, manual testers consider security issues to be the responsibility of automation engineers or security specialists. This leads to the oversight of basic bugs that can be fatal for the business.

Solution

Manual security testing is an attempt to reproduce potential attacks from the perspective of a regular user:

Checking XSS, SQL Injection, CSRF.
Manipulating cookies and sessions.
Attempting to breach authorization and privilege restrictions.

All found issues must be documented using a "Bug Report" template with a detailed description of the step, expected and actual results, as well as criticality level.

Key features:

Use of simple manual techniques (changing parameters in the URL, trying to enter dangerous values).
Checking standard vulnerabilities from the OWASP Top 10.
The need to communicate with DevOps/Backend to clarify how errors are handled and what logs are generated.

Tricky questions.

Can all critical vulnerabilities in the application be identified manually?

No. A manual approach allows for finding obvious vulnerabilities, but full coverage requires automated scanners and pentesting.

Is it sufficient to check only the login and password form for security testing?

No. All functional modules need to be checked, especially those that modify/store data, interactions with APIs, file uploads, and operations involving access rights.

Does a tester need to understand HTTP requests and responses when it comes to manual security testing?

Yes. Working with tools like DevTools, Postman, or Fiddler is key to finding security issues manually.

Common mistakes and anti-patterns

Security checks are limited to login and registration.
Ignoring vulnerabilities if they cannot be exploited immediately.
Failing to document found vulnerabilities in accordance with bug report standards.

Real-life example

Negative case

The tester only checked the login for XSS without testing other user forms and URL parameters.

Pros:

Quickly executed first-stage test.

Cons:

A critical vulnerability was overlooked in the user profile where SQL injection could be executed.

Positive case

The tester systematically checked all input forms, altered parameters in requests, detailed the findings in a bug report, and consulted with DevOps regarding error handling.