phase-7-seo-security

# Phase 7: SEO/Security

> Search optimization and security enhancement

## Purpose

Make the application discoverable through search and defend against security vulnerabilities.

## What to Do in This Phase

1. **SEO Optimization**: Meta tags, structured data, sitemap
2. **Performance Optimization**: Core Web Vitals improvement
3. **Security Enhancement**: Authentication, authorization, vulnerability defense

## Deliverables

```
docs/02-design/
├── seo-spec.md             # SEO specification
└── security-spec.md        # Security specification

src/
├── middleware/             # Security middleware
└── components/
    └── seo/                # SEO components
```

## PDCA Application

- **Plan**: Define SEO/security requirements
- **Design**: Meta tags, security policy design
- **Do**: SEO/security implementation
- **Check**: Inspection and verification
- **Act**: Improve and proceed to Phase 8

## Level-wise Application

| Level | Application Method |
|-------|-------------------|
| Starter | SEO only (minimal security) |
| Dynamic | SEO + basic security |
| Enterprise | SEO + advanced security |

## SEO Checklist

### Basic
- [ ] Per-page title, description
- [ ] Open Graph meta tags
- [ ] Canonical URL
- [ ] sitemap.xml
- [ ] robots.txt

### Structured Data
- [ ] JSON-LD schema
- [ ] Breadcrumb
- [ ] Product/Review schema (if applicable)

### Performance
- [ ] Image optimization (next/image)
- [ ] Font optimization
- [ ] Code splitting

## Security Checklist

### Authentication/Authorization
- [ ] Secure session management
- [ ] CSRF protection
- [ ] Proper permission checks

### Data Protection
- [ ] Input validation
- [ ] SQL injection defense
- [ ] XSS defense

### Communication Security
- [ ] HTTPS enforcement
- [ ] Security header configuration
- [ ] CORS policy

---

## Security Architecture (Cross-Phase Connection)

### Security Layer Structure

```
┌─────────────────────────────────────────────────────────────┐
│                     Client (Browser)                         │
├─────────────────────────────────────────────────────────────┤
│   Phase 6: UI Security                                       │
│   - XSS defense (input escaping)                            │
│   - CSRF token inclusion                                     │
│   - No sensitive info storage on client                      │
├─────────────────────────────────────────────────────────────┤
│   Phase 4/6: API Communication Security                      │
│   - HTTPS enforcement                                        │
│   - Authorization header (Bearer Token)                      │
│   - Content-Type validation                                  │
├─────────────────────────────────────────────────────────────┤
│   Phase 4: API Server Security                               │
│   - Input validation                                         │
│   - Rate Limiting                                            │
│   - Minimal error messages (prevent sensitive info exposure) │
├─────────────────────────────────────────────────────────────┤
│   Phase 2/9: Environment Variable Security                   │
│   - Secrets management                                       │
│   - Environment separation                                   │
│   - Client-exposed variable distinction                      │
└─────────────────────────────────────────────────────────────┘
```

### Security Responsibilities by Phase

| Phase | Security Responsibility | Verification Items |
|-------|------------------------|-------------------|
| **Phase 2** | Environment variable convention | NEXT_PUBLIC_* distinction, Secrets list |
| **Phase 4** | API security design | Auth method, error codes, input validation |
| **Phase 6** | Client security | XSS defense, token management, sensitive info |
| **Phase 7** | Security implementation/inspection | Full security checklist |
| **Phase 9** | Deployment security | Secrets injection, HTTPS, security headers |

---

## Client Security (Phase 6 Connection)

### XSS Defense Principles

```
⚠️ XSS (Cross-Site Scripting) Defense

1. Never use innerHTML directly
2. Always sanitize user input when rendering as HTML
3. Leverage React's automatic escaping
4. Use DOMPurify library when needed
```

### No Sensitive Information Storage

```typescript
// ❌ Forbidden: Sensitive info in localStorage
localStorage.setItem('password', password);
localStorage.setItem('creditCard', cardNumber);

// ✅ Allowed: Store only tokens (httpOnly cookies recommended)
localStorage.setItem('auth_token', token);

// ✅ More secure: httpOnly cookie (set by server)
// Set-Cookie: token=xxx; HttpOnly; Secure; SameSite=Strict
```

### CSRF Defense

```typescript
// Include CSRF token in API client
// lib/api/client.ts
private async request<T>(endpoint: string, config: RequestConfig = {}) {
  const headers = new Headers(config.headers);

  // Add CSRF token
  const csrfToken = this.getCsrfToken();
  if (csrfToken) {
    headers.set('X-CSRF-Token', csrfToken);
  }
  // ...
}
```

---

## API Security (Phase 4 Connection)

### Input Validation (Server-side)

```typescript
// All input must be validated on the server
import { z } from 'zod';

const CreateUserSchema = z.object({
  email: z.string().email(),
  password: z.string().min(8).max(100),
  name: z.string().min(1).max(50),
});

// Usage in API Route
export async function POST(req: Request) {
  const body = await req.json();

  const result = CreateUserSchema.safeParse(body);
  if (!result.success) {
    return Response.json({
      error: {
        code: 'VALIDATION_ERROR',
        message: 'Input is invalid.',
        details: result.error.flatten().fieldErrors,
      }
    }, { status: 400 });
  }

  const { email, password, name } = result.data;
}
```

### Error Message Security

```typescript
// ❌ Dangerous: Detailed error info exposure
{
  message: 'User with email test@test.com not found',
  stack: error.stack,  // Stack trace exposed!
}

// ✅ Safe: Minimal information only
{
  code: 'NOT_F