TIL - 20260713

juni·2026년 7월 13일

목록 보기

402/468

0713 백엔드 실무 심화 (20/N): 보안 점검, 취약점 대응과 운영 보안 체크리스트

✅ 1. 보안 점검이란 무엇인가?

보안 점검(Security Check)은 서비스가 외부 공격, 내부 실수, 권한 오남용, 개인정보 노출로부터 안전한지 확인하는 작업입니다.
백엔드 실무에서는 로그인, 관리자 권한, API 접근 제어, 환경변수, DB 권한, 파일 업로드, 외부 API Key, 로그, CORS, Rate Limit 같은 부분을 점검해야 합니다.
보안은 기능 개발이 끝난 뒤 “나중에 하는 것”이 아니라, 설계와 운영 전체에 계속 붙어 있어야 합니다.

기능 개발
  ↓
권한 검사
  ↓
입력값 검증
  ↓
민감정보 보호
  ↓
로그 마스킹
  ↓
배포 전 보안 점검
  ↓
운영 중 모니터링

➕ 1-1. 보안 점검이 중요한 이유

관리자 계정이 털리면 고객 정보와 주문 정보가 노출될 수 있습니다.
권한 검사가 부족하면 일반 관리자가 관리자 계정을 만들거나 엑셀을 다운로드할 수 있습니다.
환경변수나 API Key가 GitHub에 올라가면 외부 서비스 비용 피해가 생길 수 있습니다.
파일 업로드 검증이 부족하면 악성 파일이 서버에 저장될 수 있습니다.
로그에 전화번호, 토큰, 인증번호가 남으면 내부 보안 사고가 될 수 있습니다.

작은 실수:
console.log(headers)

결과:
Authorization 토큰이 로그에 남음
  ↓
로그 접근자가 관리자 권한 탈취 가능

보안 사고는 한 번 터지면 기능 버그보다 훨씬 큰 문제로 커질 수 있습니다.

✅ 2. 백엔드 보안의 기본 원칙

➕ 2-1. 최소 권한 원칙

사용자는 필요한 권한만 가져야 합니다.
관리자, DB 계정, AWS IAM, S3 권한, GitHub Actions 권한도 모두 최소 권한으로 설계해야 합니다.

나쁜 예시:
모든 관리자에게 SUPER_ADMIN 권한 부여

좋은 예시:
상담 담당자는 상담 조회/수정만 가능
마케터는 유입 통계만 조회 가능
VIEWER는 조회만 가능

➕ 2-2. 기본 차단, 필요한 것만 허용

모든 요청을 열어두고 일부만 막는 방식보다, 기본은 막고 필요한 기능만 허용하는 방식이 안전합니다.

기본:
인증 필요

예외:
고객 상품 목록 조회
고객 상담 신청
헬스체크
Webhook 수신 URL

관리자 API는 특별한 이유가 없으면 모두 인증과 권한 검사가 필요합니다.

➕ 2-3. 프론트엔드를 믿지 않는다

프론트에서 버튼을 숨기거나 입력값을 제한해도, 사용자는 직접 API를 호출할 수 있습니다.
모든 중요한 검증은 백엔드에서 다시 해야 합니다.

프론트:
엑셀 다운로드 버튼 숨김

공격자:
API URL 직접 호출

백엔드:
권한 검사 없으면 다운로드 가능

프론트 검증은 UX이고, 백엔드 검증은 보안입니다.

✅ 3. 인증 보안

인증은 사용자가 누구인지 확인하는 과정입니다.
관리자 시스템에서는 인증 보안을 특히 강하게 가져가야 합니다.

➕ 3-1. 로그인 보안 기준

비밀번호 해시 저장
로그인 실패 횟수 제한
JWT 만료 시간 설정
Refresh Token 관리
퇴사자/외주 계정 비활성화
관리자 계정 생성 권한 제한
가능하면 2FA 적용

➕ 3-2. 비밀번호 저장

비밀번호는 절대 평문으로 저장하면 안 됩니다.
bcrypt 또는 argon2 같은 해시 알고리즘을 사용해야 합니다.

import * as bcrypt from 'bcrypt';

const saltRounds = 12;
const passwordHash = await bcrypt.hash(password, saltRounds);

const isValid = await bcrypt.compare(inputPassword, admin.passwordHash);

if (!isValid) {
  throw new UnauthorizedException('이메일 또는 비밀번호가 올바르지 않습니다.');
}

로그인 실패 메시지는 너무 자세히 알려주지 않는 것이 좋습니다.
“존재하지 않는 이메일입니다”와 “비밀번호가 틀렸습니다”를 구분하면 계정 존재 여부가 노출될 수 있습니다.

✅ 4. JWT 보안

JWT는 인증 정보를 담은 토큰입니다.
편리하지만 토큰이 유출되면 만료 전까지 악용될 수 있습니다.

➕ 4-1. JWT 사용 시 주의점

JWT_SECRET은 길고 복잡하게 설정
Access Token 만료 시간을 짧게 설정
Refresh Token은 별도 관리
토큰을 로그에 남기지 않기
프론트 localStorage 저장 위험 이해
중요 관리자 기능은 추가 검증 고려

➕ 4-2. 토큰 만료 기준 예시

Access Token:
15분 ~ 1시간

Refresh Token:
7일 ~ 30일

관리자 페이지:
짧게 설정하는 편이 안전

서비스 성격에 따라 조정할 수 있습니다.
관리자 페이지는 고객 페이지보다 보안을 더 엄격히 잡는 것이 좋습니다.

✅ 5. 인가 보안

인가는 로그인한 사용자가 특정 기능을 사용할 수 있는지 확인하는 과정입니다.
관리자 API에서는 인가가 빠지면 바로 보안 사고로 이어질 수 있습니다.

➕ 5-1. 인가가 필요한 기능

상담 목록 조회
상담 상태 변경
주문 목록 조회
주문 상태 변경
상품 등록/수정/삭제
배너 등록/수정/삭제
엑셀 다운로드
관리자 계정 생성
관리자 권한 변경
시스템 설정 변경

➕ 5-2. 권한별 접근 예시

기능	SUPER_ADMIN	ADMIN	MANAGER	MARKETER	VIEWER
관리자 생성	가능	불가	불가	불가	불가
상담 상태 변경	가능	가능	담당 건만	불가	불가
엑셀 다운로드	가능	가능	제한	마스킹 통계만	불가
상품 수정	가능	가능	불가	불가	불가
유입 통계 조회	가능	가능	제한	가능	조회만

API 접근 권한과 데이터 범위 권한을 함께 봐야 합니다.
“상담 목록 조회 가능”이어도 전체 상담을 볼 수 있는지, 본인 담당만 볼 수 있는지는 별도 문제입니다.

✅ 6. 입력값 검증

백엔드는 모든 입력값을 의심해야 합니다.
DTO, class-validator, Pipe 등을 사용해 요청 데이터를 검증해야 합니다.

➕ 6-1. 검증 대상

필수값 누락
문자열 길이
전화번호 형식
이메일 형식
enum 상태값
날짜 범위
숫자 범위
파일 확장자
검색 조건
페이지네이션 limit

➕ 6-2. DTO 예시

export class CreateConsultDto {
  @IsString()
  @MinLength(2)
  @MaxLength(20)
  name: string;

  @IsString()
  @Matches(/^010\d{8}$/)
  phone: string;

  @IsInt()
  productId: number;

  @IsOptional()
  @IsString()
  source?: string;
}

➕ 6-3. 전역 ValidationPipe

app.useGlobalPipes(
  new ValidationPipe({
    whitelist: true,
    forbidNonWhitelisted: true,
    transform: true,
  }),
);

옵션	의미
`whitelist`	DTO에 없는 값 제거
`forbidNonWhitelisted`	DTO에 없는 값이 오면 에러
`transform`	요청 값을 DTO 타입으로 변환

입력값 검증은 보안뿐 아니라 데이터 품질에도 중요합니다.

✅ 7. SQL Injection 방어

SQL Injection은 사용자의 입력값을 이용해 의도하지 않은 SQL을 실행시키는 공격입니다.
Prisma 같은 ORM을 사용하면 많은 위험을 줄일 수 있지만, raw query를 사용할 때는 주의해야 합니다.

➕ 7-1. 위험한 예시

const result = await prisma.$queryRawUnsafe(`
  SELECT * FROM "Consult"
  WHERE phone = '${phone}'
`);

사용자가 입력한 값을 문자열로 직접 붙이면 위험합니다.

➕ 7-2. 안전한 예시

const result = await prisma.consult.findMany({
  where: {
    phone,
  },
});

또는 raw query가 필요하다면:

const result = await prisma.$queryRaw`
  SELECT * FROM "Consult"
  WHERE phone = ${phone}
`;

가능하면 ORM 메서드를 사용합니다.
raw query가 필요할 때도 파라미터 바인딩을 사용해야 합니다.

✅ 8. CORS 보안

CORS는 브라우저가 다른 Origin의 API를 호출할 수 있는지 제어하는 정책입니다.
운영에서는 CORS를 너무 넓게 열면 안 됩니다.

➕ 8-1. 위험한 설정

app.enableCors({
  origin: true,
  credentials: true,
});

모든 Origin을 허용하면서 credentials까지 허용하면 위험할 수 있습니다.

➕ 8-2. 안전한 설정 예시

app.enableCors({
  origin: [
    'https://www.example.com',
    'https://admin.example.com',
  ],
  credentials: true,
});

고객 페이지와 관리자 페이지 도메인을 명확히 지정하는 것이 좋습니다.
개발 환경과 운영 환경의 CORS 설정은 분리해야 합니다.

✅ 9. Rate Limit

Rate Limit은 일정 시간 동안 요청 횟수를 제한하는 보안 장치입니다.
로그인, 인증번호 발송, 상담 신청, 엑셀 다운로드 같은 기능에 중요합니다.

➕ 9-1. 적용 대상

로그인 API
비밀번호 재설정 API
인증번호 발송 API
상담 신청 API
사전예약 신청 API
엑셀 다운로드 API
Webhook API
검색 API

➕ 9-2. 기준 예시

로그인 실패:
5회 실패 시 10분 제한

인증번호 발송:
같은 전화번호 3분에 1회

상담 신청:
같은 IP 1분에 5회

엑셀 다운로드:
관리자 1분에 3회

Rate Limit은 악의적 공격뿐 아니라 실수로 인한 반복 요청도 줄여줍니다.
Redis 기반으로 IP, 계정, 전화번호 기준 제한을 걸 수 있습니다.

✅ 10. 파일 업로드 보안

파일 업로드는 백엔드 보안에서 매우 조심해야 하는 기능입니다.
이미지 업로드, 배너 업로드, 엑셀 업로드, 첨부파일 업로드가 있다면 반드시 검증해야 합니다.

➕ 10-1. 검증할 것

파일 크기 제한
확장자 제한
MIME type 확인
이미지 실제 포맷 확인
파일명 직접 사용 금지
업로드 경로 제한
실행 가능한 파일 차단
S3 public 여부 확인

➕ 10-2. 위험한 파일

.exe
.sh
.php
.jsp
.html
.js
.svg

SVG는 이미지처럼 보이지만 스크립트가 포함될 수 있어 주의가 필요합니다.
사용 목적에 따라 SVG 업로드를 막거나 별도 sanitize가 필요합니다.

➕ 10-3. 파일명 처리

나쁜 방식:
사용자가 올린 파일명 그대로 저장

위험:
../../../etc/passwd
script.js
한글/공백/특수문자 문제
중복 파일명 덮어쓰기

const fileKey = `uploads/banners/${randomUUID()}.webp`;

파일명은 UUID 기반으로 새로 만드는 것이 안전합니다.
원본 파일명은 필요한 경우 DB에 별도 저장하되, 실제 저장 경로에는 사용하지 않는 것이 좋습니다.

✅ 11. S3 보안

S3는 파일 저장에 편리하지만 public 설정을 잘못하면 개인정보나 내부 파일이 노출될 수 있습니다.

➕ 11-1. S3 파일 구분

파일 종류	접근 방식
상품 이미지	public 또는 CloudFront 공개
배너 이미지	public 또는 CloudFront 공개
고객 첨부파일	private
엑셀 Export	private + Presigned URL
백업 파일	private
내부 리포트	private

➕ 11-2. 주의할 점

버킷 전체 public 금지
파일 종류별 prefix 분리
private 파일은 Presigned URL 사용
Presigned URL 만료 시간 설정
오래된 Export 파일 자동 삭제
CloudFront OAC 검토
IAM 최소 권한 적용

엑셀 다운로드 파일은 개인정보가 들어갈 수 있으므로 절대 public으로 열면 안 됩니다.

✅ 12. 환경변수와 Secret 보안

환경변수에는 DB 주소, JWT Secret, API Key, AWS Key, 외부 API Secret이 들어갑니다.
이 값이 유출되면 서비스 전체가 위험해질 수 있습니다.

➕ 12-1. 절대 하면 안 되는 것

.env 파일 GitHub 커밋
Docker 이미지에 .env COPY
프론트엔드 코드에 Secret 포함
로그에 process.env 출력
Slack/카톡에 API Key 전송
문서에 운영 DB URL 그대로 기록

➕ 12-2. 좋은 관리 방식

.env.example만 Git에 포함
운영 Secret은 서버 또는 Secret Manager에서 관리
GitHub Actions Secrets 사용
AWS IAM Role 사용 검토
Secret 변경 이력 관리
키 유출 시 즉시 rotate

➕ 12-3. Config validation

필수 환경변수가 없으면 서버가 시작되지 않게 검증하는 것이 좋습니다.

Joi.object({
  DATABASE_URL: Joi.string().required(),
  JWT_SECRET: Joi.string().min(32).required(),
  REDIS_HOST: Joi.string().required(),
  S3_BUCKET: Joi.string().required(),
});

환경변수 누락은 배포 장애의 흔한 원인입니다.
보안과 안정성을 동시에 높일 수 있습니다.

✅ 13. 로그 보안

로그는 장애 대응에 필요하지만, 민감정보가 남으면 위험합니다.

➕ 13-1. 로그에 남기면 안 되는 정보

비밀번호
JWT Access Token
Refresh Token
Authorization Header
API Key
Secret
인증번호
전체 전화번호
주민등록번호
결제 카드 정보
고객 상담 메모 원문

➕ 13-2. 마스킹 기준

전화번호:
01012345678 → 010****5678

이메일:
test@example.com → te**@example.com

토큰:
앞 6자리만 표시 후 나머지 제거

API Key:
절대 출력하지 않음

➕ 13-3. 위험한 코드

console.log(req.headers);
console.log(process.env);
console.log(dto);

개발 중 편해서 찍은 로그가 운영에 남으면 사고가 됩니다.
배포 전 console.log와 민감정보 로그를 점검해야 합니다.

✅ 14. 관리자 페이지 보안

관리자 페이지는 고객 화면보다 더 강한 보안이 필요합니다.
관리자 페이지가 뚫리면 고객 데이터와 운영 설정이 위험해집니다.

➕ 14-1. 관리자 보안 체크

관리자 API 인증 필수
역할 기반 권한 검사
엑셀 다운로드 권한 제한
관리자 생성 권한 제한
로그인 실패 제한
퇴사자 계정 비활성화
관리자 작업 이력 저장
IP 제한 검토
2FA 검토

➕ 14-2. 관리자 작업 이력

다음 작업은 반드시 이력을 남기는 것이 좋습니다.

상담 상태 변경
주문 상태 변경
상품 수정
배너 수정
관리자 권한 변경
엑셀 다운로드
시스템 설정 변경
사전예약 오픈/종료 설정 변경

보안은 막는 것뿐 아니라, 나중에 추적할 수 있는 것도 중요합니다.

✅ 15. Webhook 보안

Webhook은 외부 서비스가 우리 서버를 호출하는 URL입니다.
URL만 알고 있으면 아무나 호출할 수 있으므로 검증이 필수입니다.

➕ 15-1. Webhook 보안 기준

Signature 검증
Secret 검증
Raw Body 기준 검증 확인
eventId 중복 처리
상태 전이 검증
payload validation
IP 제한 가능 여부 검토
실패 이력 저장

➕ 15-2. 위험한 구조

POST /api/webhooks/payment

요청 body:
{
  "orderId": 123,
  "status": "PAID"
}

검증 없이 주문 상태 PAID 변경

공격자가 임의로 결제 완료 요청을 보낼 수 있습니다.
반드시 외부 서비스에서 보낸 요청인지 검증해야 합니다.

✅ 16. 의존성 보안

npm 패키지, Docker 이미지, OS 패키지도 취약점이 생길 수 있습니다.
오래된 라이브러리를 계속 사용하면 보안 위험이 커집니다.

➕ 16-1. 점검 명령어

npm audit

pnpm audit

➕ 16-2. 주의할 것

무조건 최신 버전이 정답은 아님
major 업데이트는 breaking change 확인
보안 패치는 우선순위 높게 검토
사용하지 않는 패키지 제거
Docker base image도 주기적으로 업데이트

보안 업데이트는 중요하지만, 운영 서비스에서는 테스트 없이 무작정 올리면 장애가 날 수 있습니다.
업데이트 후 빌드, 테스트, 주요 기능 QA가 필요합니다.

✅ 17. 서버/인프라 보안

백엔드 코드만 안전해도 서버 설정이 허술하면 위험합니다.

➕ 17-1. EC2 보안 체크

SSH 22번 포트 접근 제한
키 페어 안전 보관
root 로그인 비활성화 검토
불필요한 포트 차단
보안 그룹 최소화
OS 패키지 업데이트
디스크 권한 확인
로그 접근 권한 제한

➕ 17-2. Security Group 기준

외부 허용:
80, 443

제한 허용:
22 SSH는 내 IP만

내부 허용:
EC2 → RDS 5432
EC2 → Redis 6379

외부 차단:
RDS 5432 public open 금지
Redis 6379 public open 금지

DB와 Redis는 외부 인터넷에 직접 열면 안 됩니다.
필요한 서버에서만 접근 가능하게 제한해야 합니다.

✅ 18. DB 보안

DB는 서비스의 핵심 데이터가 있는 곳입니다.
DB 계정과 접근 권한을 신중하게 관리해야 합니다.

➕ 18-1. DB 보안 체크

운영 DB public access 최소화
강한 비밀번호 사용
DB 계정 권한 최소화
백업/스냅샷 접근 제한
직접 접속 가능한 사람 제한
운영 DB 접속 이력 관리
읽기 전용 계정 분리 검토
정기 백업 확인

➕ 18-2. 운영 DB 접근 원칙

운영 DB 직접 수정은 최소화
수정 전 SELECT 먼저 실행
UPDATE/DELETE에는 구체적인 WHERE 조건
위험 작업 전 백업
실행 SQL 기록
수정 후 검증 쿼리 실행

운영 DB에 직접 붙어서 작업하는 것은 항상 위험합니다.
데이터 정정 작업은 문서와 검증 쿼리를 같이 남겨야 합니다.

✅ 19. 보안 사고 대응

보안 사고는 일반 장애보다 더 신중하게 대응해야 합니다.
특히 개인정보나 Secret 유출 가능성이 있으면 즉시 차단과 조사부터 해야 합니다.

➕ 19-1. Secret 유출 시 대응

1. 유출된 키 즉시 폐기/회전
2. GitHub commit history 확인
3. 외부 API 사용량 확인
4. 관련 로그 확인
5. 새 키 발급 후 서비스 반영
6. 재발 방지: Secret scanning, .gitignore 점검

➕ 19-2. 개인정보 노출 의심 시 대응

1. 노출 범위 즉시 확인
2. 추가 접근 차단
3. 로그/다운로드 이력 확인
4. 어떤 개인정보가 노출됐는지 파악
5. 내부 보고 및 법적 대응 필요 여부 확인
6. 재발 방지 조치

보안 사고는 혼자 판단하지 말고 회사 책임자에게 빠르게 공유해야 합니다.
로그와 이력이 있어야 노출 범위를 파악할 수 있습니다.

✅ 20. 배포 전 보안 체크리스트

1. 새 API에 인증/권한 검사가 있는가?
2. 관리자 API가 public으로 열려 있지 않은가?
3. DTO validation이 적용되어 있는가?
4. SQL raw query에 사용자 입력이 직접 붙지 않는가?
5. CORS 운영 Origin이 제한되어 있는가?
6. 새 환경변수가 Secret으로 안전하게 관리되는가?
7. console.log에 민감정보가 찍히지 않는가?
8. 파일 업로드 제한이 적용되어 있는가?
9. 엑셀 다운로드 권한과 이력이 있는가?
10. Webhook 검증이 적용되어 있는가?
11. Rate Limit이 필요한 API에 적용되어 있는가?
12. S3 파일 접근 권한이 적절한가?

보안 체크리스트는 배포 전 QA와 같이 보는 것이 좋습니다.
특히 관리자 기능, 개인정보, 외부 API, 파일 업로드가 있는 배포는 더 꼼꼼히 봐야 합니다.

✅ 21. 운영 보안 점검 루틴

➕ 21-1. 매일 또는 배포 후 확인

API 500/401/403 급증 여부
관리자 로그인 실패 반복
엑셀 다운로드 이력
Webhook 검증 실패 증가
외부 API 실패 증가
비정상 IP 요청

➕ 21-2. 매주 확인

관리자 계정 목록
비활성화해야 할 계정
불필요한 권한
S3 public 파일 여부
CloudWatch 로그 민감정보 여부
npm audit 주요 결과

➕ 21-3. 매월 확인

AWS IAM 권한 점검
보안 그룹 점검
RDS public access 여부
사용하지 않는 Access Key 삭제
백업/스냅샷 권한 점검
Secret rotation 필요 여부

보안은 한 번 점검하고 끝나는 것이 아니라 주기적으로 확인해야 합니다.

✅ 22. AI를 활용해 보안 점검을 할 때 질문법

AI에게 보안 점검을 요청할 때는 서비스 구조, 관리자 기능, 인증 방식, 파일 업로드 여부, 외부 API, 인프라 구조를 함께 알려줘야 합니다.
“보안 괜찮아?”라고만 물으면 너무 일반적인 답변이 나올 수 있습니다.

➕ 22-1. 좋은 질문 예시

NestJS + Prisma + PostgreSQL + Redis + AWS EC2/RDS/S3 기반 온라인 휴대폰 판매몰 백엔드 보안 점검을 하고 싶어.

상황:
1. 고객은 상품 조회와 상담 신청을 할 수 있음
2. 관리자 페이지에는 상담 관리, 주문 관리, 상품 관리, 배너 관리, 엑셀 다운로드 기능이 있음
3. JWT 기반 관리자 로그인 사용
4. 역할은 SUPER_ADMIN, ADMIN, MANAGER, VIEWER가 있음
5. 엑셀 다운로드에는 이름/전화번호 같은 개인정보가 포함될 수 있음
6. 알림톡/SMS 외부 API를 사용함
7. S3에는 상품 이미지, 배너 이미지, 엑셀 Export 파일이 저장됨
8. Webhook으로 외부 결제/알림 결과를 받을 수 있음
9. EC2 + Nginx + PM2 또는 Docker로 운영함
10. Redis는 Queue와 Rate Limit에 사용함

요청:
- 인증/JWT 보안 체크
- 관리자 권한 보안 체크
- 입력값 검증 체크
- CORS/Rate Limit 체크
- 파일 업로드/S3 보안 체크
- 환경변수/Secret 관리 체크
- 로그 마스킹 기준
- Webhook 보안 체크
- AWS EC2/RDS/Redis 보안 체크
- 배포 전 보안 체크리스트
를 실무 기준으로 정리해줘.

➕ 22-2. AI 답변 검증 기준

프론트엔드 버튼 숨김을 보안으로 착각하지 않는가?
백엔드 권한 검사와 데이터 범위 제한을 포함하는가?
JWT Secret, Access Token, Refresh Token 관리 기준을 설명하는가?
입력값 검증과 raw SQL 위험을 설명하는가?
CORS를 전체 허용하지 말라고 하는가?
파일 업로드와 S3 public 위험을 설명하는가?
로그에 토큰/전화번호/API Key를 남기지 말라고 하는가?
Webhook signature 검증과 eventId 중복 처리를 포함하는가?
AWS 보안 그룹과 RDS/Redis public access 차단을 언급하는가?
Secret 유출 시 회전/폐기 대응을 설명하는가?

📌 요약

보안 점검은 백엔드 서비스가 외부 공격, 내부 실수, 권한 오남용, 개인정보 노출로부터 안전한지 확인하는 작업입니다.
백엔드 보안의 기본은 최소 권한, 기본 차단, 백엔드 검증, 민감정보 보호입니다.
비밀번호는 bcrypt/argon2로 해시 저장하고, 로그인 실패 제한, JWT 만료 시간, Refresh Token 관리, 관리자 계정 비활성화 기준을 갖춰야 합니다.
프론트엔드에서 버튼을 숨기는 것은 보안이 아니며, 모든 관리자 API는 백엔드에서 인증과 권한 검사를 해야 합니다.
입력값 검증은 DTO와 ValidationPipe로 처리하고, raw SQL에는 사용자 입력을 문자열로 직접 붙이면 안 됩니다.
CORS는 운영 도메인만 허용하고, 로그인/인증번호/상담 신청/엑셀 다운로드 같은 API에는 Rate Limit을 적용하는 것이 좋습니다.
파일 업로드는 파일 크기, 확장자, MIME type, 저장 경로, S3 public 여부를 반드시 검증해야 합니다.
환경변수와 Secret은 GitHub, Docker 이미지, 프론트 코드, 로그에 포함되면 안 되며, 유출 시 즉시 폐기/회전해야 합니다.
로그에는 JWT, Refresh Token, API Key, 인증번호, 전체 전화번호, 고객 상담 메모 같은 민감정보를 남기면 안 됩니다.
운영 보안은 배포 전 체크리스트뿐 아니라 매일/매주/매월 점검 루틴으로 관리해야 합니다.

juni

이전 포스트

TIL - 20260712

다음 포스트

TIL - 20260713

TIL

0713 백엔드 실무 심화 (20/N): 보안 점검, 취약점 대응과 운영 보안 체크리스트

✅ 1. 보안 점검이란 무엇인가?

➕ 1-1. 보안 점검이 중요한 이유

✅ 2. 백엔드 보안의 기본 원칙

➕ 2-1. 최소 권한 원칙

➕ 2-2. 기본 차단, 필요한 것만 허용

➕ 2-3. 프론트엔드를 믿지 않는다

✅ 3. 인증 보안

➕ 3-1. 로그인 보안 기준

➕ 3-2. 비밀번호 저장

✅ 4. JWT 보안

➕ 4-1. JWT 사용 시 주의점

➕ 4-2. 토큰 만료 기준 예시

✅ 5. 인가 보안

➕ 5-1. 인가가 필요한 기능

➕ 5-2. 권한별 접근 예시

✅ 6. 입력값 검증

➕ 6-1. 검증 대상

➕ 6-2. DTO 예시

➕ 6-3. 전역 ValidationPipe

✅ 7. SQL Injection 방어

➕ 7-1. 위험한 예시

➕ 7-2. 안전한 예시

✅ 8. CORS 보안

➕ 8-1. 위험한 설정

➕ 8-2. 안전한 설정 예시

✅ 9. Rate Limit

➕ 9-1. 적용 대상

➕ 9-2. 기준 예시

✅ 10. 파일 업로드 보안

➕ 10-1. 검증할 것

➕ 10-2. 위험한 파일

➕ 10-3. 파일명 처리

✅ 11. S3 보안

➕ 11-1. S3 파일 구분

➕ 11-2. 주의할 점

✅ 12. 환경변수와 Secret 보안

➕ 12-1. 절대 하면 안 되는 것

➕ 12-2. 좋은 관리 방식

➕ 12-3. Config validation

✅ 13. 로그 보안

➕ 13-1. 로그에 남기면 안 되는 정보

➕ 13-2. 마스킹 기준

➕ 13-3. 위험한 코드

✅ 14. 관리자 페이지 보안

➕ 14-1. 관리자 보안 체크

➕ 14-2. 관리자 작업 이력

✅ 15. Webhook 보안

➕ 15-1. Webhook 보안 기준

➕ 15-2. 위험한 구조

✅ 16. 의존성 보안

➕ 16-1. 점검 명령어

➕ 16-2. 주의할 것

✅ 17. 서버/인프라 보안

➕ 17-1. EC2 보안 체크

➕ 17-2. Security Group 기준

✅ 18. DB 보안

➕ 18-1. DB 보안 체크

➕ 18-2. 운영 DB 접근 원칙

✅ 19. 보안 사고 대응

➕ 19-1. Secret 유출 시 대응

➕ 19-2. 개인정보 노출 의심 시 대응

✅ 20. 배포 전 보안 체크리스트

✅ 21. 운영 보안 점검 루틴

➕ 21-1. 매일 또는 배포 후 확인

➕ 21-2. 매주 확인

➕ 21-3. 매월 확인

✅ 22. AI를 활용해 보안 점검을 할 때 질문법

➕ 22-1. 좋은 질문 예시

➕ 22-2. AI 답변 검증 기준

📌 요약

TIL - 20260712

TIL - 20260714

0개의 댓글