🧑🏫
멘토 한마디
오늘도 한 칸 올라가 볼까요? 천천히, 그러나 멈추지 않고 — 그게 진짜 실력이 됩니다. 💪
회원가입, 로그인, 글쓰기 — 사용자가 데이터를 보내는 거의 모든 곳에 폼(form)이 있습니다. 폼을 제대로 다루는 것은 편의의 문제이자 보안의 문제입니다. 이번 챕터에서 그 기본기를 잡습니다.
폼의 기본 구조
폼은 <form> 안에 입력칸 <input>들을 담고, 제출 버튼으로 마무리합니다. 각 입력칸에는 서버가 값을 알아볼 수 있게 name을 붙입니다.
<form method="post" action="/signup">
<label for="email">이메일</label>
<input id="email" name="email" type="email" required>
<button type="submit">가입</button>
</form>- type — 입력 종류:
text,email,password,number등. 종류에 맞는 키보드·검사가 따라옵니다. - name — 서버로 전송될 때의 이름표. 이게 없으면 값이 서버에 전달되지 않습니다.
- label — 입력칸의 설명.
for를 입력칸id와 맞추면 라벨을 눌러도 칸이 선택됩니다(접근성).
핵심
placeholder(흐린 예시 글자)는 label을 대신할 수 없습니다. 입력을 시작하면 사라져 버리기 때문입니다. 설명은 반드시 label로 따로 두세요.검증은 두 번 한다
입력 검증(validation)에는 두 층이 있습니다. 둘 다 필요하지만, 믿을 수 있는 쪽은 서버뿐입니다.
| 층 | 목적 | 신뢰 |
|---|---|---|
| 클라이언트(브라우저) | 빠른 피드백으로 사용자 편의 | 믿을 수 없음(우회 가능) |
| 서버(백엔드) | 진짜 데이터 보호 | 믿어야 하는 최종 방어선 |
브라우저의 required나 자바스크립트 검사는 친절한 안내일 뿐, 공격자는 그것을 끄고 요청을 직접 보냅니다. 그래서 서버는 받은 모든 값을 다시 검사해야 합니다. "모든 입력은 의심하라"가 원칙입니다.입력을 안전하게 다루기
- 이스케이프/새니타이즈 — 사용자가 넣은 글을 화면에 그대로 출력하면, 악성 스크립트가 섞여 실행되는 XSS 공격이 가능합니다. 출력 시 특수문자를 무력화(이스케이프)해야 합니다.
- 플레이스홀더로 DB에 — 입력값을 SQL에 직접 붙이지 말고 플레이스홀더(
?)로 전달합니다(SQL 인젝션 방지). - 필요한 것만 받기 — 받을 항목을 정해 두고, 예상 밖의 값은 버립니다.
주의 클라이언트 검증만 믿고 서버 검증을 생략하면, 빈 값·이상한 형식·악성 코드가 그대로 저장될 수 있습니다. 클라이언트 검증은 'UX용', 서버 검증은 '보안용'이라고 기억하세요.
AD
이해도 퀴즈 (10문항)
정답 6개 이상 → +185 XP배운 내용을 정확히 점검해 보세요. 10문항 중 6문항 이상 맞히면 챕터가 완료되고 경험치(XP)가 적립됩니다. 난이도는 문항마다 하·중·상으로 섞여 있어요.
하 쉬움중 보통상 어려움
중
Q1.입력칸의 값이 서버로 전송될 때의 '이름표' 역할을 하는 속성은?
하
Q2.비밀번호 입력칸에 알맞은 input type은?
중
Q3.label의 for를 입력칸 id와 맞추면 좋은 점은?
중
Q4.placeholder가 label을 대신할 수 없는 이유는?
중
Q5.입력 검증에서 '믿을 수 있는' 최종 방어선은?
상
Q6.클라이언트 검증과 서버 검증의 역할을 옳게 짝지은 것은?
중
Q7."모든 입력은 의심하라"는 원칙이 뜻하는 것은?
상
Q8.사용자 입력을 화면에 그대로 출력할 때 생길 수 있는 공격은?
중
Q9.입력값을 데이터베이스에 안전하게 넣는 방법은?
상
Q10.클라이언트 검증만 믿고 서버 검증을 생략하면 일어날 수 있는 일은?
← 이전 챕터 · CH4
데이터베이스 입문
테이블 개념과 CRUD(생성·조회·수정·삭제)를 MariaDB의 SQL 예시로 익힙니다.
다음 챕터 · CH6 →
로그인·세션·인증 기초
인증과 인가의 차이, 비밀번호 해시 저장, 세션과 쿠키, 그리고 HTTPS·서버측 권한 검증의 필요성을 익힙니다. 계속 이어가기 🚀
📚 함께 보면 좋은 정보글
AD