PortfolioAbout This Topic
In business systems, security is paramount. Unauthorized access or data leaks can damage a company's reputation. This project adopted a defense-in-depth security design to ensure small businesses can use it with confidence.
Defense in Depth
Relying on a single defense measure is risky. By defending with multiple layers, even if one is breached, the next layer provides protection.
Verify legitimate access with secret token
Block mass requests in short timeframes
Reject invalid data before processing
Encrypted storage + auto-renewal
Layer 1: Token Authentication
Communication from GAS uses a secret token of 32+ characters. Access from third parties who don't know this token is automatically rejected.
| Item | Details |
|---|---|
| Token length | 32+ characters (hard to guess) |
| Transmission method | Included in HTTP header |
| Verification location | Compared with server-side environment variable |
| On mismatch | Immediately return 401 Unauthorized |
Token Management Tips
Tokens are managed in GAS settings (script properties), so they can be changed immediately if compromised. No code changes required.
Layer 2: Rate Limiting
A mechanism that automatically blocks a flood of requests in a short time.
Identify by client IP + last 8 characters of token
Check request count in the past minute
What Rate Limiting Prevents
- Malicious mass access: Denial of service attacks
- Operational errors: Duplicate processing from button mashing
- Infinite loops: Endless requests from program bugs
Response Header Notifications
API responses include the remaining request count.
| Header | Meaning | Example |
|---|---|---|
| X-RateLimit-Remaining | Remaining requests | 45 |
| X-RateLimit-Reset | Reset time (Unix timestamp) | 1705363200 |
Layer 3: Input Validation
Strictly check if submitted data is in the correct format before processing.
| Item | Validation | Invalid Example |
|---|---|---|
| Date | yyyy-mm-dd format | 2024/01/15 (slash separator) |
| Amount | Number (up to 3 decimal places) | 1,000 (with comma) |
| Tags | Maximum 10 | 11 or more tags |
| Idempotency Key | 8+ characters | Key too short |
When Validation Finds Issues
Returns an error before processing begins, preventing invalid data from being sent to the invoicing service.
Validation errors return details about which field is invalid and why, making it easy to identify the cause and fix quickly.
Layer 4: Secure Credential Management
Credentials (access tokens) needed to connect to the invoicing service require special handling.
Three Credential Management Techniques
| Technique | Description | Benefit |
|---|---|---|
| Encrypted storage | Store in encrypted cloud storage like Redis | Reduce leak risk |
| Auto-renewal | Automatically get new token 60 seconds before expiry | No manual management |
| Distributed lock | Prevent duplicate updates even with concurrent access | Prevent token inconsistency |
Get token before API call
More than 60 seconds remaining?
Make request with valid token
How Distributed Locking Works
If multiple requests try to refresh the token simultaneously:
- Same token refreshed multiple times (wasted API calls)
- Old and new tokens mixed (inconsistency)
Distributed locking ensures only one instance can refresh the token at a time.
Security Design Summary
| Threat | Countermeasure | Layer |
|---|---|---|
| Unauthorized access | Token authentication | Layer 1 |
| DDoS attacks | Rate limiting | Layer 2 |
| Invalid input | Input validation | Layer 3 |
| Credential leak | Encrypted storage + auto-renewal | Layer 4 |
What This Design Achieves
For Operations
- Reduced security workload: Automated protection mechanisms
- Easy incident response: Just change the token
- Audit compliance: Track history with structured logs
For Users
- Safe to use: Protected by defense in depth
- Transparency: Know remaining rate limit
- Quick error notification: Immediate awareness of issues