Home>

I have a question about where to check user input for clean architecture.
For example, suppose you have an app that saves your name in the DB when you enter it.
AndSpecificationStates that users can store names of up to 14 characters.

In this case, refer to the figure below.

Quoted
http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

We believe that Entities is in charge of checking if the name is 14 characters or less.
This is because it is stated in the specifications whether it is 14 characters or less, and we consider this to be a business rule.

Then, as a measure against SQL injection, if the name entered by the user contains dangerous characters that operate the DB,
Suppose I want to implement a process that converts. This "processing to convert dangerous characters that operate DB" is not described in the specifications,
I don't think it's a business rule. Therefore, I think that this process should be described in the outer layer of Entities/Use Cases. Is this idea correct?

We apologize for the inconvenience, but we look forward to hearing from you.

  • Answer # 1

    Then, as a measure against SQL injection, if the name entered by the user contains dangerous characters that operate the DB, we will implement a process to convert it.

    If I were to implement it, I wouldn't implement "processing that converts if the name entered by the user contains dangerous characters that operate the DB". I don't check it either. SQL injection can be avoided by using placeholders when issuing SQL, so it is avoided by the implementation around DB (Repository).
    SQL injection countermeasures are required because SQL is issued. Not required if saving to a regular file. Since SQL is issued, it is necessary to take measures against SQL injection. So we will deal with it wherever we issue the SQL.

  • Answer # 2

    Then, as a measure against SQL injection, if the name entered by the user contains dangerous characters that operate the DB, we will implement a process to convert it. This "process of converting dangerous characters that operate DB" is not described in the specifications, so I think that it cannot be said to be a business rule.

    That's right.

    Therefore, I think that this process should be described in the outer layer of Entities/Use Cases. Is this idea correct?

    I don't understand the meaning of "description", but it is not necessary to write the contents of SQL injection countermeasures in documents such as specifications and design documents one by one. This is because "SQL injection countermeasures are commonplace". You don't have to write as much as you don't write to connect to the database server before each SQL call.
    Then, where to write it is somewhere in the implementation rule book, or in the method design document etc., describe the method of SQL call (including O/R mapper etc.), and SQL injection countermeasures are automatically taken in it. Make sure you are.
    In this way, it is sufficient if the document for countermeasures against implementation vulnerabilities such as SQL injection is comprehensively described in the system (in some cases, within the department), and it is not described in the document for each processing part. ..