Archive
About
Rules

아카이브

2023

09월 16일
03월 05일표준 출력은 무엇이든 로깅하는데 사용하여서는 안 됩니다.
03월 05일"enum" 필드는 공개되어 있지 않고 불변해야 합니다.
03월 05일Collection에 대한 반복은 Collection의 타입으로 수행되어야합니다.
03월 05일정규식은 서비스 거부 공격에 취약하지 않아야 합니다.
03월 05일암호 블록 체인 IV는 예측할 수 없어야 합니다.
03월 05일취약한 SSL/TLS 프로토콜을 사용해서는 안 됩니다.
03월 05일암호화 키 생성은 강력한 매개 변수를 기반으로 해야 합니다.
03월 05일LDAP 연결은 인증되어야 합니다.
03월 05일SSL/TLS 연결 중에 서버 인증서를 확인해야 합니다.
03월 04일Deprecated된 항목은 어노테이션과 Javadoc태그를 가지고 있어야한다.
03월 04일매소드 재정의 및 구현에 @Override 를 사용해야합니다.
03월 04일Throwable과 에러는 잡지 않아야 합니다.
03월 04일안전하지 않은 임시 파일 생성 방법을 사용해서는 안 됩니다.
03월 04일SSL/TLS 연결 중에 서버 호스트 이름을 확인해야 합니다.
03월 04일암호화 알고리즘은 보안 모드 및 패딩 체계와 함께 사용해야 합니다.
03월 01일암호 알고리즘은 강력해야 합니다.
03월 01일JWT에 서명하고 검증해야 합니다.
03월 01일AWS IAM 정책은 권한 에스컬레이션을 허용하지 않아야 합니다.
02월 28일파일은 너무 많은 코드 라인을 가져서는 안됩니다.
02월 28일매직넘버는 사용되서는 안됩니다.
02월 28일메소드는 너무 많은 리턴문을 포함해서는 안됩니다.
02월 28일'switch-case' 구문은 너무 많은 코드 라인을 포함해서는 안됩니다.
02월 28일클래스들은 너무 많은 클래스들과 결합되어서는 안됩니다.(단일 책임 원칙)
02월 28일메소드는 너무 많은 코드 라인을 가져서는 안됩니다.
02월 28일클래스는 너무 많은 메소드를 가져서는 안됩니다.
02월 28일3항 연산자는 사용하지 않아야 합니다.
02월 28일변수들은 서로 관계가 없기 전에는 선언되어서는 안됩니다.
02월 26일Catch 블락은 가능한 결합 되어야 합니다
02월 26일다이아몬드 연산("<>")이 사용 되어야 합니다
02월 26일"catch" 구문은 rethrow 이상의 역할을 해야합니다
02월 26일배열은 loop를 이용해서 복사되어선 안됩니다
02월 24일OS 커맨드는 커맨드 인젝션 공격에 취약하지 않아야 합니다.
02월 24일LDAP 쿼리는 인젝션 공격에 취약하지 않아야 합니다.
02월 24일I/O 함수 호출은 경로 인젝션 공격에 취약하지 않아야 합니다.
02월 24일XPath 표현식은 인젝션 공격에 취약하지 않아야 합니다.
02월 24일데이터베이스에 연결할 때는 안전한 비밀번호를 사용해야 합니다.
02월 22일HTTP 요청 리디렉션은 위조 공격에 노출되어서는 안됩니다.
02월 22일데이터베이스 쿼리는 인젝션 공격에 취약하지 않아야 합니다.
02월 22일HTTP 요청 리디렉션은 위조 공격에 노출되어서는 안됩니다.
02월 22일역직렬화는 인젝션 공격에 취약하지 않아야 합니다.
02월 22일HTTP 요청 리디렉션은 위조 공격에 노출되어서는 안됩니다.
02월 19일Jump 구문은 중복되어선 안됩니다
02월 19일varargs 파라미터를 위해 배열이 만들어져선 안됩니다
02월 18일표현식(Expressions) 은 너무 복잡해서는 안됩니다.
02월 18일"if", "for", "while", "switch" 그리고 "try" 와 같은 제어문은 너무 깊게 중첩되어서는 안됩니다.
02월 18일클래스는 너무 많은 필드를 포함해서는 안됩니다.
02월 18일파일들은 오직 하나의 최상위 클래스 혹은 인터페이스에만 포함되어야 합니다.
02월 18일내부 클래스(inner class) 는 너무 많은 코드 라인을 가져서는 안됩니다.
02월 18일클래스는 너무 많은 "static" 구문을 가져와서는(imports) 안됩니다.
02월 15일하나로 합칠 수 있는 if문은 합치는 것이 좋습니다
02월 15일메소드는 너무 많은 매개변수를 가져서는 안됩니다.
02월 15일반복문은 하나를 초과한 "break" 또는 "continue" 구문을 포함할 수 없습니다.
02월 15일메소드는 너무 복잡해서는 안됩니다.
02월 15일Boxing과 Unboxing이 곧장 번복되선 안됩니다
02월 15일가능하면 "Stream" 체이닝은 간단하게 표현되어야 합니다
02월 15일"StandardCharsets" 상수가 우선시 되어야 합니다
02월 14일Exception 타입들은 catch block에서 'instanceof'을 이용해 처리되어선 안됩니다
02월 14일Exceptions은 로그 처리되거나 rethrow 둘 중 하나만 되어야지 둘 다 되어선 안됩니다
02월 14일멍청한 수학적인 계산은 수행되어선 안됩니다
02월 14일테스트 assertion은 메세지를 포함해야 합니다.
02월 14일boolean 값과 null 값 자체는 assertion에서 사용해서는 안됩니다.
02월 14일테스트 함수 이름은 네이밍 컨벤션을 준수해야 합니다.
02월 14일JUnit4에서 새로운 JUnit5 어노테이션으로 교체하세요.
02월 13일멍청한 문자열 작업을 수행해서는 안 됩니다
02월 13일정적 메서드만 있는 클래스를 인스턴스화해선 안 됩니다
02월 13일"Lock"에 사용되는 객체는 "synchronized"되어선 안됩니다
02월 13일테스트는 지정된 소스 디렉토리에 유지되어야 합니다.
02월 13일유닛 테스트는 예외를 던저야 합니다.
02월 13일테스트는 랜덤 데이터 대신에 고정된 데이터를 사용해야 합니다.
02월 13일Mockito 객체는 초기화되어야 합니다.
02월 13일Mockito 인수 일치자(argument matchers)는 모든 파라미터가 사용되어야 합니다.
02월 05일Simple class names이 사용되어야 합니다.
02월 05일"final" 클래스는 "protected" 멤버를 가져선 안됩니다
02월 05일이스케이프 유니코드 문자는 사용되어선 안됩니다
02월 05일추상 메소드는 중복되어선 안됩니다
02월 05일NoSQL 오퍼레이션은 인젝션 공격에 취약하지 않아야 합니다.
02월 05일동적 코드 실행은 인젝션 공격에 취약하지 않아야 합니다.
02월 05일HTTP 응답은 세션 고정에 취약하지 않아야 합니다.
02월 04일내부 클래스에서만 호출되는 "private" 메서드는 해당 내부 클래스로 이동해야 합니다
02월 04일메서드가 상수를 반환하면 안됩니다
02월 04일logger는 자신을 소유한 클래스의 이름을 사용해야 합니다
02월 03일의미없이 괄호를 중복해선 안됩니다
02월 03일레이블은 사용되선 안됩니다
02월 02일"switch" 구문은 너무 많은 "case" 구문을 가져서는 안됩니다.
02월 02일필드의 이름은 그것을 소유한 클래스의 이름과 중복되어서는 안됩니다.
02월 02일JUnit 규칙은 사용되어야 합니다.
02월 02일테스트 클래스는 네이밍 컨벤션을 준수해야 합니다.
02월 02일메소드의 인지 복잡도가 너무 높아서는 안됩니다.
02월 02일JUnit5 테스트 클래스와 함수는 기본 패키지 가시성을 가져야 합니다.
02월 02일체이닝된 AssertJ assertion은 해당 전용 assertion으로 간소화되어야 합니다.
02월 02일연속된 AssertJ assertThat() 문은 체이닝되어야 합니다.
02월 02일Mockito 함수인 verify(), when(), given()를 호출할 때는 간소화되어야 합니다.
02월 02일사용하지 않는 할당은 제거해야 합니다.
02월 02일Boolean 검사는 반전되지 않아야 합니다.
02월 02일클래스 메서드의 첫 번째 인수는 명명 규칙을 따라야 합니다.
02월 02일함수 매개변수의 기본값을 수정하거나 할당하면 안됩니다.
02월 02일암시적 문자열 및 바이트 연결이 혼동되어서는 안 됩니다.
02월 01일Try-catch은 중첩되어선 안됩니다
02월 01일"readObject"는 "synchronized"여선 안됩니다
02월 01일"writeObject"가 클래스에서 유일한 "synchronized" 코드여선 안됩니다
02월 01일3항 연산자는 중첩되지 않아야 합니다
01월 30일JUnit4의 @Ignored와 JUnit5의 @Disabled 어노테이션은 테스트를 비활성화 하거나 이론적 해석을 제공하는데 사용되어야만 합니다.
01월 30일Assertion 인수 올바른 순서로 통과돼야 합니다.
01월 30일JUnit ExpectedException 규칙을 통해 예외를 테스트하는 것은 다른 assertion과 섞여서는 안됩니다.
01월 30일AssertJ assertion인 allMatch와 doesNotContains는 empty에 대해서도 테스트되어야 합니다.
01월 29일런타임 예외를 테스트할 때는 하나의 함수 호출만 필요합니다.
01월 29일JUnit assertTrue/assertFalse는 해당 전용 assertion으로 간소화되어야만 합니다.
01월 29일AssertJ의 assertThatThrownBy는 혼자 사용되어서는 안됩니다.
01월 29일테스트 함수는 너무 많은 assertion을 포함하면 안됩니다.
01월 28일문자열의 printf-style 포맷은 제대로 사용되어야 합니다
01월 28일메소드는 중복된 방식으로 구현되어선 안됩니다.
01월 28일"else"는 매칭되는 "if"가 명확하게 보여야 합니다
01월 27일"for" 루프 안의 increment 절은 루프의 카운터를 수정해야 합니다
01월 27일상위 클래스의 "static" 멤버는 파생 클래스를 통해 접근해선 안됩니다
01월 27일필드주입 대신 생성자 주입을 사용해야합니다.
01월 27일한 줄짜리 조건문은 들여쓰기를 지켜서 써야합니다
01월 27일스프링 컴포넌트는 생성자 주입을 사용해야 합니다.
01월 27일JUnit5 테스트 클래스와 함수는 조용히 무시되어서는 안됩니다.
01월 27일AssertJ 설정은 apply 되어야 합니다.
01월 27일AssertJ 함수에서 assertion context를 설정하려면 assertion 이전에 나와야 합니다.
01월 27일Assertions은 자기 자신과 비교해서는 안됩니다.
01월 27일스프링의 ModelAndViewAssert Assertions 가 다른 assertions 대신 사용되어야 합니다.
01월 27일테스트는 안정적이어야 합니다.
01월 26일메서드와 필드의 이름은 같아선 안되고, 대소문자 몇 개로 구분해선 안됩니다
01월 26일하위 클래스의 멤버 변수가 상위 클래스의 멤버 변수를 접근하지 못하게 이름이 중복 처리되선 안 됩니다
01월 24일"Thread.sleep" 은 테스트에서 사용되면 안 됩니다.
01월 24일유사한 테스트는 하나의 Parameterized 테스트로 그룹화시켜야 합니다.
01월 19일"Cloneables"은 "clone"을 구현해야 합니다
01월 19일메소드의 파라미터는 base 타입으로 지정되는게 좋습니다.
01월 19일"java.nio.file.Files#delete" 사용을 권장합니다.
01월 18일Public 메소드의 파라미터에 구현을 선택하는 전달인자(selector argument)가 들어가면 안됩니다.
01월 18일Private 생성자 밖에 없는 클래스는 final로 선언되어야 합니다.
01월 18일스프링 컴포넌트의 변수들은 주입되어야합니다.
01월 18일스프링 "@Controller" 클래스들은 "@Scope" 를 사용하지 않아야 합니다.
01월 18일스프링 빈들은 "@ComponentScan" 에 의해 고려되어야합니다.
01월 17일"secure" 플래그 없이 쿠키를 생성하는 것은 보안에 취약할 수 있습니다.
01월 17일"@RequestMapping" 의 변형된 어노테이션을 사용하는 것이 더 선호됩니다.
01월 16일상속의 깊이가 너무 깊어선 안됩니다.
01월 16일유틸리티 클래스들은 public 생성자를 갖고 있어선 안됩니다.
01월 16일안전한 HTTP 메소드와 안전하지 않은 HTTP 메소드를 모두 허용하는 것은 보안에 민감할 수 있습니다.
01월 16일디버그 기능이 활성화 된 채로 프로덕션에 코드를 제공하는 것은 보안에 민감할 수 있습니다.
01월 15일조건절에서 어떤 두개의 분기가 같은 구현을 가지고 있어선 안됩니다.
01월 15일SQL 쿼리 형식은 보안에 민감할 수 있습니다.
01월 15일"@RequestMapping" 메소드는 "private" 일 수 없습니다.
01월 15일허용적인 CORS 정책을 가지는것은 보안에 민감할 수 있습니다.
01월 14일문자열 리터럴이 같은지 비교할 때는 왼쪽에 배치하여야 합니다.
01월 14일String 리터럴이 중복 사용되어선 안됩니다.
01월 14일"NOSONAR"" 주석을 추적할 수 있습니다.
01월 14일"NOPMD" 억제 주석을 추적할 수 있습니다.
01월 14일"CHECKSTYLE:OFF"" 억제 주석을 추적할 수 있습니다.
01월 14일public 이 아닌 메소드는 "@Transactional" 을 사용해서는 안됩니다.
01월 14일"ThreadGroup"을 사용해선 안됩니다
01월 14일팩토리 메서드 주입은 "@Configuration" 클래스에서 사용해야 합니다.
01월 14일인증 바이패스를 방지하기 위해 OpenSAML2 가 설정되어야 합니다.
01월 14일사용자 열거(User enumeration)를 허용하는 것은 보안에 민감합니다.
01월 14일추상 클래스의 생성자는 public으로 선언되어선 안됩니다.
01월 14일조건부 구조의 모든 분기에 정확히 동일한 구현이 되어서는 안됩니다.
01월 14일인스턴스 및 클래스 메서드에는 하나 이상의 위치 매개 변수가 있어야 합니다.
01월 12일테스트 함수는 유사한 기능의 어노테이션과 함께 어노테이션을 달면 안됩니다.
01월 12일"Consumer" 인수를 사용하는 "AssertJ assertions"는 Consumer 인터페이스 안에 "assertion"을 포함해야 합니다.
01월 11일JUnit assertions는 run 함수와 사용되면 안됩니다.
01월 11일JUnit4에서 setUp(), tearDown() 함수는 올바른 어노테이션으로 시작해야합니다.
01월 11일어떤 클래스의 private 접근 제한자가 아닌 모든 함수를 Mocking 하는 것은 피해야 합니다.
01월 10일Assertion 함수의 예외를 잡기 위해서는 try-catch 구문의 try 블럭이 사용되어서는 안됩니다.
01월 10일Checked Exception을 테스트할 때, 하나의 함수만 호출해야 합니다.
01월 09일테스트케이스는 테스트를 포함해야 합니다.
01월 09일JUnit 테스트는 super 메소드를 호출해야 합니다.
01월 09일테스트는 `assertions`를 포함해야 합니다.
01월 09일JUnit5 내부 테스트 클래스는 @Nested 어노테이션을 붙여야 합니다.
01월 09일호환되지 않는 타입을 비교하는 `Assertions`을 생성하면 안됩니다.
01월 08일Enum 값을 갖는 Set은 EnumSet을 사용하는게 좋습니다.
01월 08일String은 반복문에서 '+'을 이용하여 연결 연산을 해선 안됩니다
01월 08일Regex 패턴들이 불필요하게 만들어져선 안됩니다.
01월 07일Synchronized 클래스인 Vector, Hashtable, Stack, StringBuffer를 사용하면 안 됩니다.
01월 07일래퍼 클래스가 "toString"이나 "compareTo"을 호출하기 위해 사용되어선 안됩니다.
01월 07일상수는 인터페이스에 정의되지 않아야 합니다.
01월 07일"Garbage Collector"실행은 JVM에 의해서만 제어되어야 합니다.
01월 07일"Strings"에서 기본 자료형으로 변환할 때는 Parse가 쓰여야 합니다.
01월 07일Boxing과 Unboxing이 즉시 번복되서는 안 됩니다.
01월 07일어떤 String의 SubString에 존재하는 값을 찾기 위해, 원본 String을 이용하는 것이 더 좋습니다.
01월 06일Enum 값을 키 값으로 갖는 Map은 EnumMap을 사용하는게 좋습니다.
01월 06일객체를 만드는 목적이 `getClass()`밖에 없다면 객체를 만들지 마세요.
01월 06일같은 집합을 여러번 반복하는 것보다 하나로 합치는게 낫습니다.
01월 05일"String", "BigInteger", "BigDecimal" 같은 기본 자료형의 래퍼 클래스 생성자를 사용하지 말아야합니다.
01월 05일내부 클래스를 소유하고 있는 클래스를 참조하지 않는 클래스는 "static"으로 선언되어야 합니다
01월 05일Functional Interfaces는 대체 가능한 전문화된 인터페이스를 사용해야 합니다.
01월 05일CSRF 보호를 비활성화 하는 것은 보안에 취약할 수 있습니다.
01월 05일약한 해싱 알고리즘을 사용하는 것은 보안에 취약할 수 있습니다.
01월 04일"URL.hashCode"과 "URL.equals" 사용을 피하세요.
01월 04일Collection 메소드에서 O(n) 성능을 가진 메소드는 사용에 주의해야 합니다
01월 04일lock을 사용하고 있다면 "Thread.sleep(...)"보다 "wait(...)"을 우선해서 사용해야합니다.
01월 04일Assertions는 완료되어야 합니다.
01월 04일"write(byte[],int,int)"은 오버라이딩 되어야 합니다
01월 04일"ThreadLocal" 더 이상 사용하지 않으면 확실히 제거해야 합니다.
01월 04일Kubernetes 구문 분석 실패
01월 04일capabilities를 설정하는 것은 보안에 민감합니다.
01월 04일프리빌리지드 모드에서 컨테이너를 실행하는 것은 보안에 민감합니다.
01월 04일Docker 소켓 노출은 민감합니다.
01월 04일프로세스 권한 상승을 허용하는 것은 보안에 민감합니다.
01월 04일호스트 운영 체제 네임스페이스 사용은 보안에 민감합니다.
01월 03일"finalize"에서는 필드 값을 null로 변경해선 안됩니다.
01월 03일"ResultSet.isLast()"은 사용하지 않는 것이 좋습니다.
01월 03일"Preconditions"과 로깅 매개변수에는 evaluation(계산식)을 사용하지 않습니다.
01월 03일"read(byte[],int,int)"은 오버라이딩 되어야 합니다
01월 03일Primitive 배열에는 "Arrays.stream"이 사용되어야 합니다
01월 03일중요한 파일 시스템 경로를 마운팅하는 것은 보안에 민감합니다.
01월 02일"deleteOnExit"을 사용해선 안됩니다.
01월 02일"entrySet()"은 key value가 둘 다 필요한 경우에만 사용되어야 합니다.
01월 02일Primitive 배열에는 "Arrays.stream"이 사용되어야 합니다

2022

12월 30일Statement를 하나만 포함하는 람다는, 이 Statement가 {}(block scope) 안에 있어선 안됩니다.
12월 30일하나의 메소드만 갖는 익명 내부 클래스는 람다식으로 교체돼야 합니다
12월 30일멤버 변수가 없는 추상 클래스는 인터페이스로 전환되어야 합니다.
12월 30일람다를 사용할 때, 입력 매개 변수가 하나라면 괄호를 제거해야 합니다.
12월 30일Lambdas 대신 메소드 참조를 사용하는게 좋습니다.
12월 30일표준 Functional Interface들을 재정의하면 안 됩니다.
12월 30일Try-with-resources 구문을 사용하는 것이 좋습니다.
12월 30일"java.time"은 날짜와 시간을 표기하는데에만 사용되어야 합니다
12월 30일람다에선 타입을 사용하는 것이 좋습니다.
12월 30일아파치 공통 라이브러리에서 "DateUtils.truncate"은 사용해선 안됩니다
12월 30일"null"은 "Optional"에서 사용되선 안됩니다.
12월 30일Value-based 클래스들이 lock을 하는데 사용되선 안됩니다
12월 30일Value-based 객체는 Serialize되선 안됩니다.
12월 30일데이터베이스 쿼리는 injection 공격에 취약해서는 안됩니다.
12월 30일Java 8에서 "Files.exists"는 사용되선 안됩니다.
12월 30일"Map.get"이나 value 테스트는 단일 메서드 호출을 사용하여야 합니다.
12월 30일"Stream.peek" 사용은 조심해야 합니다
12월 30일Stream 중간(Intermediate) 연산은 사용되지 않은 채 남겨져선 안됩니다.
12월 30일한번 소비된 Stream pipeline은 재사용해선 안됩니다
12월 30일"ThreadLocal.withInitial"을 우선해서 사용하는게 좋습니다.
12월 30일"HttpSecurity" URL 패턴은 올바르게 정렬되어있어야 합니다.
12월 30일영속 개체들(Persist Entities)은 "@RequestMapping" 메소드의 인수로 사용해서는 안됩니다.
12월 30일Java 기능이 Guava보다 우선시되어야 합니다.
12월 30일비밀번호는 평문 혹은 빠른 해싱 알고리즘을 통해 저장되지 않아야 합니다.
12월 30일유저의 인증 중에 새 세션을 생성해야합니다.
12월 29일"list::add"대신 "Streams"과 "collect"을 사용해야 합니다
12월 29일같은 클래스 내의 메소드에서 호환되지 않는 "@Transactional" 메소드를 호출하지 않아야 합니다.
12월 29일@Controller 클래스에서 @SessionAttributes 를 사용하는 경우 SessionStatus 객체의 setComplete 메소드를 호출해야 합니다.
12월 29일@SpringBootApplication" 과 @ComponentScan 어노테이션은 default package 에서 사용되서는 안됩니다.

© Sonarkube 2021, Powered by Jekyll & TeXt Theme.

검색