@daniel-da-silva-alves/sddk 2.0.0 → 2.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +23 -0
- package/README.md +21 -4
- package/bin/cli.js +4 -4
- package/package.json +7 -2
- package/sddk/plugin.json +1 -1
- package/sddk/skills/code-review/SKILL.md +142 -141
- package/sddk/skills/code-review/references/anti-ai-design-patterns.md +90 -90
- package/sddk/skills/code-review/references/refactoring-severity-guide.md +60 -60
- package/sddk/skills/code-review/references/security-checklist.md +59 -59
- package/sddk/skills/fullstack-development/SKILL.md +79 -78
- package/sddk/skills/fullstack-development/references/clean-code-rules.md +65 -65
- package/sddk/skills/fullstack-development/references/self-review-checklist.md +42 -42
- package/sddk/skills/implementation-planning/SKILL.md +65 -64
- package/sddk/skills/implementation-planning/references/manual-tests-template.md +53 -53
- package/sddk/skills/implementation-planning/references/microtask-template.md +47 -47
- package/sddk/skills/software-requirements-specification/SKILL.md +46 -45
- package/sddk/skills/software-requirements-specification/references/checklist-template.md +48 -48
- package/sddk/skills/software-requirements-specification/references/ieee-830-template.md +94 -94
- package/sddk/skills/software-requirements-specification/references/socratic-interview-guide.md +65 -65
- package/sddk/skills/system-design-document/SKILL.md +108 -107
- package/sddk/skills/system-design-document/references/architecture-patterns.md +59 -59
- package/sddk/skills/system-design-document/references/documentation-sources-guide.md +69 -69
- package/sddk/skills/system-design-document/references/sdd-template.md +117 -117
- package/sddk/skills/system-design-document/references/standards-api-template.md +47 -47
- package/sddk/skills/system-design-document/references/standards-architecture-template.md +42 -42
- package/sddk/skills/system-design-document/references/standards-coding-template.md +64 -64
- package/sddk/skills/system-design-document/references/standards-design-system-template.md +81 -81
- package/sddk/skills/system-design-document/references/standards-naming-template.md +59 -59
- package/sddk/skills/system-design-document/references/standards-onboarding-guide.md +80 -80
- package/sddk/skills/system-design-document/references/tech-stack-analysis.md +37 -37
|
@@ -1,69 +1,69 @@
|
|
|
1
|
-
# Anti-Design
|
|
1
|
+
# Anti-AI-Design — 8 Patterns to Detect and Reject
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
These are patterns that expose AI-generated code without human curation. The agent MUST detect and fix all of them during Code Review.
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
-
##
|
|
7
|
+
## Pattern 1: Emojis in Interface
|
|
8
8
|
|
|
9
|
-
###
|
|
10
|
-
Emojis
|
|
9
|
+
### What to detect
|
|
10
|
+
Emojis used as textual content in user interface elements.
|
|
11
11
|
|
|
12
|
-
###
|
|
13
|
-
-
|
|
14
|
-
-
|
|
15
|
-
- Headings
|
|
16
|
-
-
|
|
17
|
-
-
|
|
18
|
-
-
|
|
12
|
+
### Where to look
|
|
13
|
+
- Button text
|
|
14
|
+
- Form labels
|
|
15
|
+
- Headings and titles
|
|
16
|
+
- Input placeholders
|
|
17
|
+
- Feedback/toast messages
|
|
18
|
+
- Navigation (menus, breadcrumbs)
|
|
19
19
|
|
|
20
|
-
###
|
|
20
|
+
### Examples
|
|
21
21
|
|
|
22
|
-
❌ **
|
|
22
|
+
❌ **Bad**:
|
|
23
23
|
```html
|
|
24
|
-
<button>🚀
|
|
25
|
-
<h1>📊 Dashboard
|
|
26
|
-
<input placeholder="🔍
|
|
27
|
-
<span>✅
|
|
24
|
+
<button>🚀 Submit Project</button>
|
|
25
|
+
<h1>📊 Sales Dashboard</h1>
|
|
26
|
+
<input placeholder="🔍 Search..." />
|
|
27
|
+
<span>✅ Saved successfully!</span>
|
|
28
28
|
```
|
|
29
29
|
|
|
30
|
-
✅ **
|
|
30
|
+
✅ **Good**:
|
|
31
31
|
```html
|
|
32
|
-
<button>
|
|
33
|
-
<h1>Dashboard
|
|
34
|
-
<input placeholder="
|
|
35
|
-
<span>
|
|
32
|
+
<button>Submit Project</button>
|
|
33
|
+
<h1>Sales Dashboard</h1>
|
|
34
|
+
<input placeholder="Search products, orders, or customers" />
|
|
35
|
+
<span>Changes saved</span>
|
|
36
36
|
```
|
|
37
37
|
|
|
38
|
-
###
|
|
39
|
-
Emojis
|
|
38
|
+
### Exception
|
|
39
|
+
Emojis are acceptable in: user-generated content (chat, comments), data fields (not UI), and when the project's design system explicitly includes them.
|
|
40
40
|
|
|
41
41
|
---
|
|
42
42
|
|
|
43
|
-
##
|
|
43
|
+
## Pattern 2: Generic CSS/Tailwind
|
|
44
44
|
|
|
45
|
-
###
|
|
46
|
-
|
|
45
|
+
### What to detect
|
|
46
|
+
Visual styles applied without coherence with a design system. Random colors, inconsistent sizes, ad-hoc spacing.
|
|
47
47
|
|
|
48
|
-
###
|
|
48
|
+
### Examples
|
|
49
49
|
|
|
50
|
-
❌ **
|
|
50
|
+
❌ **Bad**:
|
|
51
51
|
```html
|
|
52
52
|
<div class="bg-blue-500 text-white p-4 rounded-lg shadow-lg">
|
|
53
|
-
<h2 class="text-2xl font-bold mb-2">
|
|
54
|
-
<p class="text-gray-200">
|
|
53
|
+
<h2 class="text-2xl font-bold mb-2">Title</h2>
|
|
54
|
+
<p class="text-gray-200">Description here</p>
|
|
55
55
|
</div>
|
|
56
56
|
```
|
|
57
57
|
|
|
58
|
-
✅ **
|
|
58
|
+
✅ **Good** (with design tokens):
|
|
59
59
|
```html
|
|
60
60
|
<div class="bg-surface-primary text-on-surface p-card rounded-card shadow-card">
|
|
61
|
-
<h2 class="text-heading-md font-heading mb-spacing-sm">
|
|
62
|
-
<p class="text-body-md text-on-surface-secondary">
|
|
61
|
+
<h2 class="text-heading-md font-heading mb-spacing-sm">Title</h2>
|
|
62
|
+
<p class="text-body-md text-on-surface-secondary">Description here</p>
|
|
63
63
|
</div>
|
|
64
64
|
```
|
|
65
65
|
|
|
66
|
-
|
|
66
|
+
Or with CSS variables:
|
|
67
67
|
```css
|
|
68
68
|
.card {
|
|
69
69
|
background: var(--color-surface-primary);
|
|
@@ -75,29 +75,29 @@ Ou com CSS variables:
|
|
|
75
75
|
|
|
76
76
|
---
|
|
77
77
|
|
|
78
|
-
##
|
|
78
|
+
## Pattern 3: Obvious Comments
|
|
79
79
|
|
|
80
|
-
###
|
|
81
|
-
|
|
80
|
+
### What to detect
|
|
81
|
+
Comments that restate in natural language what the code already says.
|
|
82
82
|
|
|
83
|
-
###
|
|
83
|
+
### Examples
|
|
84
84
|
|
|
85
|
-
❌ **
|
|
85
|
+
❌ **Bad**:
|
|
86
86
|
```typescript
|
|
87
|
-
//
|
|
87
|
+
// Import the users service
|
|
88
88
|
import { UserService } from './user.service';
|
|
89
89
|
|
|
90
|
-
//
|
|
90
|
+
// Set the counter variable to 0
|
|
91
91
|
let counter = 0;
|
|
92
92
|
|
|
93
|
-
//
|
|
93
|
+
// Increment the counter
|
|
94
94
|
counter++;
|
|
95
95
|
|
|
96
|
-
//
|
|
96
|
+
// Return the response
|
|
97
97
|
return response;
|
|
98
98
|
```
|
|
99
99
|
|
|
100
|
-
✅ **
|
|
100
|
+
✅ **Good** (no comments — the code is self-explanatory):
|
|
101
101
|
```typescript
|
|
102
102
|
import { UserService } from './user.service';
|
|
103
103
|
let counter = 0;
|
|
@@ -107,79 +107,79 @@ return response;
|
|
|
107
107
|
|
|
108
108
|
---
|
|
109
109
|
|
|
110
|
-
##
|
|
110
|
+
## Pattern 4: Generic Names
|
|
111
111
|
|
|
112
|
-
###
|
|
113
|
-
|
|
112
|
+
### What to detect
|
|
113
|
+
Variables, functions, and components with names that don't describe their content or purpose.
|
|
114
114
|
|
|
115
|
-
###
|
|
115
|
+
### Prohibited Names List
|
|
116
116
|
|
|
117
|
-
|
|
|
117
|
+
| Context | Generic Names ❌ |
|
|
118
118
|
|:---|:---|
|
|
119
|
-
|
|
|
120
|
-
|
|
|
121
|
-
|
|
|
122
|
-
|
|
|
119
|
+
| Variables | `data`, `result`, `temp`, `item`, `obj`, `val`, `info`, `stuff` |
|
|
120
|
+
| Functions | `handleClick`, `handleChange`, `handleSubmit`, `getData`, `processData`, `doStuff`, `check` |
|
|
121
|
+
| Components | `Card`, `Modal`, `List`, `Item`, `Container`, `Wrapper` (without qualifier) |
|
|
122
|
+
| Types | `Props`, `Data`, `Response`, `Payload` (without qualifier) |
|
|
123
123
|
|
|
124
124
|
---
|
|
125
125
|
|
|
126
|
-
##
|
|
126
|
+
## Pattern 5: Monolithic Components
|
|
127
127
|
|
|
128
|
-
###
|
|
129
|
-
|
|
128
|
+
### What to detect
|
|
129
|
+
Component files with more than ~150 meaningful lines that mix multiple responsibilities.
|
|
130
130
|
|
|
131
|
-
###
|
|
132
|
-
-
|
|
133
|
-
-
|
|
134
|
-
-
|
|
135
|
-
-
|
|
131
|
+
### Signs
|
|
132
|
+
- Multiple unrelated `useState`/`useEffect` in the same component
|
|
133
|
+
- Extensive conditional rendering (multiple nested `if/else` or ternaries)
|
|
134
|
+
- Business logic mixed with UI
|
|
135
|
+
- Form, table, and chart in the same component
|
|
136
136
|
|
|
137
137
|
---
|
|
138
138
|
|
|
139
|
-
##
|
|
139
|
+
## Pattern 6: Repetitive Boilerplate Code
|
|
140
140
|
|
|
141
|
-
###
|
|
142
|
-
|
|
141
|
+
### What to detect
|
|
142
|
+
Identical or near-identical code patterns repeated across multiple files without abstraction.
|
|
143
143
|
|
|
144
|
-
###
|
|
145
|
-
-
|
|
146
|
-
-
|
|
147
|
-
-
|
|
148
|
-
-
|
|
144
|
+
### Signs
|
|
145
|
+
- Repeated fetch/API calls without a centralized client
|
|
146
|
+
- Duplicated validations across forms
|
|
147
|
+
- Repeated loading/error state handling
|
|
148
|
+
- Duplicated date/currency formatting
|
|
149
149
|
|
|
150
150
|
---
|
|
151
151
|
|
|
152
|
-
##
|
|
152
|
+
## Pattern 7: "YouTube Tutorial" UI
|
|
153
153
|
|
|
154
|
-
###
|
|
155
|
-
Interfaces
|
|
154
|
+
### What to detect
|
|
155
|
+
Interfaces that look like screenshots from generic tutorials — functional but without visual identity.
|
|
156
156
|
|
|
157
|
-
###
|
|
158
|
-
- Cards
|
|
159
|
-
-
|
|
160
|
-
-
|
|
161
|
-
-
|
|
162
|
-
-
|
|
163
|
-
-
|
|
157
|
+
### Signs
|
|
158
|
+
- Cards with default framework `box-shadow` without customization
|
|
159
|
+
- Generic gradients (`linear-gradient(to right, blue, purple)`)
|
|
160
|
+
- Default Tailwind colors without customization (`blue-500`, `gray-700`)
|
|
161
|
+
- Basic grid layout without visual hierarchy
|
|
162
|
+
- Default browser typography (no custom font)
|
|
163
|
+
- Generic library icons without curation
|
|
164
164
|
|
|
165
165
|
---
|
|
166
166
|
|
|
167
|
-
##
|
|
167
|
+
## Pattern 8: Generic Placeholder Text
|
|
168
168
|
|
|
169
|
-
###
|
|
170
|
-
|
|
169
|
+
### What to detect
|
|
170
|
+
Text that demonstrates lack of care with the actual interface content.
|
|
171
171
|
|
|
172
|
-
###
|
|
172
|
+
### Prohibited Text List
|
|
173
173
|
|
|
174
|
-
|
|
|
174
|
+
| Context | Generic Text ❌ |
|
|
175
175
|
|:---|:---|
|
|
176
|
-
|
|
|
177
|
-
|
|
|
176
|
+
| Content | "Lorem ipsum dolor sit amet" |
|
|
177
|
+
| Buttons | "Click here", "Submit", "Send", "OK", "Go" |
|
|
178
178
|
| Links | "Read more", "Learn more", "Click here" |
|
|
179
179
|
| Placeholders | "Enter text here", "Type something...", "Search..." |
|
|
180
180
|
| Labels | "Label", "Field", "Input" |
|
|
181
181
|
| Headings | "Title", "Heading", "Section" |
|
|
182
182
|
| Error msgs | "An error occurred", "Something went wrong" |
|
|
183
183
|
|
|
184
|
-
###
|
|
185
|
-
|
|
184
|
+
### What to use instead
|
|
185
|
+
Real and descriptive text based on the application domain, extracted from the SRS functional requirements.
|
|
@@ -1,96 +1,96 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Refactoring Severity Classification Guide
|
|
2
2
|
|
|
3
|
-
Use
|
|
3
|
+
Use this guide to classify each issue found during Code Review. The classification determines the **immediate action** to be taken.
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
-
##
|
|
7
|
+
## Severities
|
|
8
8
|
|
|
9
|
-
### 🔴
|
|
9
|
+
### 🔴 Critical — Immediate Execution
|
|
10
10
|
|
|
11
|
-
Issues
|
|
11
|
+
Issues that **must be fixed in the same session** before considering the feature complete.
|
|
12
12
|
|
|
13
|
-
####
|
|
13
|
+
#### Criteria for Classifying as Critical:
|
|
14
14
|
|
|
15
|
-
|
|
|
15
|
+
| Category | Examples |
|
|
16
16
|
|:---|:---|
|
|
17
|
-
| **
|
|
18
|
-
| **
|
|
19
|
-
| **
|
|
20
|
-
| **
|
|
17
|
+
| **Security** | SQL injection, XSS, IDOR, exposed secrets, plaintext passwords |
|
|
18
|
+
| **Functional bug** | Feature doesn't work per SRS, crash in main flow |
|
|
19
|
+
| **Severe SDD violation** | Architecture implemented differently from design (e.g.: business logic in controller) |
|
|
20
|
+
| **Data loss** | Destructive operations without confirmation, missing validation on deletes |
|
|
21
21
|
|
|
22
|
-
####
|
|
23
|
-
1.
|
|
24
|
-
2.
|
|
25
|
-
3.
|
|
22
|
+
#### Action:
|
|
23
|
+
1. Fix the code directly
|
|
24
|
+
2. Document what was fixed in the review report
|
|
25
|
+
3. If there are more than 5 critical fixes, create microtasks and return to Skill 4
|
|
26
26
|
|
|
27
27
|
---
|
|
28
28
|
|
|
29
|
-
### 🟡
|
|
29
|
+
### 🟡 Medium — Document in Backlog
|
|
30
30
|
|
|
31
|
-
Issues
|
|
31
|
+
Issues that **affect quality but don't prevent functionality**. Should be resolved before the next release or sprint.
|
|
32
32
|
|
|
33
|
-
####
|
|
33
|
+
#### Criteria for Classifying as Medium:
|
|
34
34
|
|
|
35
|
-
|
|
|
35
|
+
| Category | Examples |
|
|
36
36
|
|:---|:---|
|
|
37
|
-
| **Code smell** |
|
|
38
|
-
| **Naming** |
|
|
39
|
-
| **Anti-
|
|
40
|
-
| **
|
|
41
|
-
| **
|
|
37
|
+
| **Code smell** | Code duplication, overly long functions, high cyclomatic complexity |
|
|
38
|
+
| **Naming** | Inconsistent names across files, mixed conventions |
|
|
39
|
+
| **Anti-AI detected** | Emojis in UI, generic CSS, obvious comments |
|
|
40
|
+
| **Componentization** | Component with multiple responsibilities (but functional) |
|
|
41
|
+
| **Configuration** | Open CORS, missing rate limiting, frontend-only validation |
|
|
42
42
|
|
|
43
|
-
####
|
|
44
|
-
1.
|
|
45
|
-
2.
|
|
46
|
-
3.
|
|
43
|
+
#### Action:
|
|
44
|
+
1. Document in `.specs/features/{feature}/refactoring-backlog.md`
|
|
45
|
+
2. Include: file, line, description, fix suggestion
|
|
46
|
+
3. Prioritize within the backlog
|
|
47
47
|
|
|
48
48
|
---
|
|
49
49
|
|
|
50
|
-
### 🟢
|
|
50
|
+
### 🟢 Low — Document in Backlog (Low Priority)
|
|
51
51
|
|
|
52
|
-
Issues
|
|
52
|
+
Issues that are **optional improvements** to aesthetics, performance, or organization. Not urgent.
|
|
53
53
|
|
|
54
|
-
####
|
|
54
|
+
#### Criteria for Classifying as Low:
|
|
55
55
|
|
|
56
|
-
|
|
|
56
|
+
| Category | Examples |
|
|
57
57
|
|:---|:---|
|
|
58
|
-
| **
|
|
59
|
-
| **
|
|
60
|
-
| **
|
|
61
|
-
| **
|
|
62
|
-
| **DX** |
|
|
58
|
+
| **Optimization** | Queries that could be more efficient (but work) |
|
|
59
|
+
| **Style** | Inconsistent formatting (that a linter would fix) |
|
|
60
|
+
| **Documentation** | Missing JSDoc on public functions |
|
|
61
|
+
| **Organization** | File could be in a different directory (but works where it is) |
|
|
62
|
+
| **DX** | Uninformative log messages |
|
|
63
63
|
|
|
64
|
-
####
|
|
65
|
-
1.
|
|
66
|
-
2.
|
|
67
|
-
3.
|
|
64
|
+
#### Action:
|
|
65
|
+
1. Document in `.specs/features/{feature}/refactoring-backlog.md`
|
|
66
|
+
2. Mark as low priority
|
|
67
|
+
3. Resolve when time is available
|
|
68
68
|
|
|
69
69
|
---
|
|
70
70
|
|
|
71
|
-
##
|
|
71
|
+
## Decision Tree
|
|
72
72
|
|
|
73
73
|
```
|
|
74
|
-
|
|
75
|
-
├──
|
|
76
|
-
└──
|
|
77
|
-
└──
|
|
78
|
-
├──
|
|
79
|
-
└──
|
|
80
|
-
└──
|
|
81
|
-
├──
|
|
82
|
-
└──
|
|
74
|
+
Does the code work incorrectly or have a security flaw?
|
|
75
|
+
├── YES → 🔴 Critical → FIX NOW
|
|
76
|
+
└── NO
|
|
77
|
+
└── Does the code violate best practices, conventions, or the SDD?
|
|
78
|
+
├── YES → 🟡 Medium → BACKLOG (priority)
|
|
79
|
+
└── NO
|
|
80
|
+
└── Can the code be improved but is it OK?
|
|
81
|
+
├── YES → 🟢 Low → BACKLOG (when possible)
|
|
82
|
+
└── NO → ✅ No issue
|
|
83
83
|
```
|
|
84
84
|
|
|
85
|
-
##
|
|
85
|
+
## Backlog Entry Format
|
|
86
86
|
|
|
87
87
|
```markdown
|
|
88
|
-
### RB-{
|
|
89
|
-
- **
|
|
90
|
-
- **
|
|
91
|
-
- **
|
|
92
|
-
- **
|
|
93
|
-
- **
|
|
94
|
-
- **
|
|
95
|
-
- **
|
|
88
|
+
### RB-{number}: {Descriptive title}
|
|
89
|
+
- **Severity**: 🟡 Medium / 🟢 Low
|
|
90
|
+
- **File**: `{path/to/file.ext}`
|
|
91
|
+
- **Line(s)**: {L42-L58}
|
|
92
|
+
- **Category**: {Code Smell | Naming | Anti-AI | Security | Performance | Organization}
|
|
93
|
+
- **Description**: {What's wrong}
|
|
94
|
+
- **Suggestion**: {How to fix}
|
|
95
|
+
- **Estimated effort**: {Low | Medium | High}
|
|
96
96
|
```
|
|
@@ -1,22 +1,22 @@
|
|
|
1
|
-
# Checklist
|
|
1
|
+
# Security Checklist for Code Review
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Simplified checklist based on the OWASP Top 10, adapted for individual feature code review.
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
-
## 1.
|
|
7
|
+
## 1. Injection (SQL, XSS, Command)
|
|
8
8
|
|
|
9
|
-
- [ ] **SQL Injection**: Queries
|
|
10
|
-
- [ ] **XSS**:
|
|
11
|
-
- [ ] **Command Injection**:
|
|
12
|
-
- [ ] **Template Injection**: Templates (Handlebars, EJS, Jinja)
|
|
9
|
+
- [ ] **SQL Injection**: Queries use parameterization/prepared statements (never string concatenation)
|
|
10
|
+
- [ ] **XSS**: User inputs are sanitized before rendering in the DOM
|
|
11
|
+
- [ ] **Command Injection**: User inputs are NEVER passed directly to system command execution
|
|
12
|
+
- [ ] **Template Injection**: Templates (Handlebars, EJS, Jinja) escape variables by default
|
|
13
13
|
|
|
14
|
-
###
|
|
14
|
+
### What to verify
|
|
15
15
|
```typescript
|
|
16
16
|
// ❌ SQL Injection
|
|
17
17
|
db.query(`SELECT * FROM users WHERE id = '${userId}'`);
|
|
18
18
|
|
|
19
|
-
// ✅
|
|
19
|
+
// ✅ Parameterized
|
|
20
20
|
db.query('SELECT * FROM users WHERE id = $1', [userId]);
|
|
21
21
|
```
|
|
22
22
|
|
|
@@ -24,38 +24,38 @@ db.query('SELECT * FROM users WHERE id = $1', [userId]);
|
|
|
24
24
|
// ❌ XSS
|
|
25
25
|
element.innerHTML = userInput;
|
|
26
26
|
|
|
27
|
-
// ✅
|
|
27
|
+
// ✅ Sanitized
|
|
28
28
|
element.textContent = userInput;
|
|
29
29
|
```
|
|
30
30
|
|
|
31
31
|
---
|
|
32
32
|
|
|
33
|
-
## 2.
|
|
33
|
+
## 2. Authentication
|
|
34
34
|
|
|
35
|
-
- [ ]
|
|
36
|
-
- [ ]
|
|
37
|
-
- [ ] Refresh tokens
|
|
38
|
-
- [ ]
|
|
39
|
-
- [ ] Logout
|
|
35
|
+
- [ ] Passwords are hashed with a strong algorithm (bcrypt, argon2, scrypt) — never MD5/SHA1
|
|
36
|
+
- [ ] JWT tokens have defined expiration
|
|
37
|
+
- [ ] Refresh tokens are stored securely (httpOnly cookies, not localStorage)
|
|
38
|
+
- [ ] Login attempts are limited (rate limiting / account lockout)
|
|
39
|
+
- [ ] Logout invalidates the session/token on the server
|
|
40
40
|
|
|
41
41
|
---
|
|
42
42
|
|
|
43
|
-
## 3.
|
|
43
|
+
## 3. Authorization
|
|
44
44
|
|
|
45
|
-
- [ ]
|
|
46
|
-
- [ ]
|
|
47
|
-
- [ ] Roles/permissions
|
|
48
|
-
- [ ]
|
|
45
|
+
- [ ] Each endpoint verifies the authenticated user's permissions
|
|
46
|
+
- [ ] No IDOR (Insecure Direct Object Reference) — user A cannot access user B's data
|
|
47
|
+
- [ ] Roles/permissions are validated on the backend (never only on the frontend)
|
|
48
|
+
- [ ] Admin endpoints are properly protected
|
|
49
49
|
|
|
50
|
-
###
|
|
50
|
+
### What to verify
|
|
51
51
|
```typescript
|
|
52
|
-
// ❌ IDOR —
|
|
52
|
+
// ❌ IDOR — any authenticated user can access any order
|
|
53
53
|
app.get('/api/orders/:id', async (req, res) => {
|
|
54
54
|
const order = await orderRepo.findById(req.params.id);
|
|
55
55
|
return res.json(order);
|
|
56
56
|
});
|
|
57
57
|
|
|
58
|
-
// ✅
|
|
58
|
+
// ✅ Ownership verification
|
|
59
59
|
app.get('/api/orders/:id', async (req, res) => {
|
|
60
60
|
const order = await orderRepo.findById(req.params.id);
|
|
61
61
|
if (order.userId !== req.user.id) return res.status(403).json({ error: 'Forbidden' });
|
|
@@ -65,67 +65,67 @@ app.get('/api/orders/:id', async (req, res) => {
|
|
|
65
65
|
|
|
66
66
|
---
|
|
67
67
|
|
|
68
|
-
## 4.
|
|
68
|
+
## 4. Sensitive Data Exposure
|
|
69
69
|
|
|
70
|
-
- [ ]
|
|
71
|
-
- [ ]
|
|
72
|
-
- [ ] .env
|
|
73
|
-
- [ ]
|
|
70
|
+
- [ ] Passwords never appear in API responses
|
|
71
|
+
- [ ] Sensitive data (SSN, credit card, tokens) are not logged
|
|
72
|
+
- [ ] .env and secrets are not committed to git (.gitignore configured)
|
|
73
|
+
- [ ] Production errors don't expose stack traces or internal details to the client
|
|
74
74
|
|
|
75
|
-
###
|
|
75
|
+
### What to verify
|
|
76
76
|
```typescript
|
|
77
|
-
// ❌
|
|
77
|
+
// ❌ Exposes password
|
|
78
78
|
return res.json(user);
|
|
79
79
|
|
|
80
|
-
// ✅
|
|
80
|
+
// ✅ Omits sensitive fields
|
|
81
81
|
const { password, ...safeUser } = user;
|
|
82
82
|
return res.json(safeUser);
|
|
83
83
|
```
|
|
84
84
|
|
|
85
85
|
---
|
|
86
86
|
|
|
87
|
-
## 5.
|
|
87
|
+
## 5. Security Configuration
|
|
88
88
|
|
|
89
|
-
- [ ] CORS
|
|
90
|
-
- [ ]
|
|
91
|
-
- [ ] HTTPS enforced
|
|
92
|
-
- [ ] Secrets/tokens
|
|
89
|
+
- [ ] CORS is configured to allow only necessary origins (not `*` in production)
|
|
90
|
+
- [ ] Security headers configured (CSP, X-Frame-Options, X-Content-Type-Options)
|
|
91
|
+
- [ ] HTTPS enforced in production
|
|
92
|
+
- [ ] Secrets/tokens are not hardcoded in source code
|
|
93
93
|
|
|
94
|
-
###
|
|
94
|
+
### What to verify
|
|
95
95
|
```typescript
|
|
96
|
-
// ❌ CORS
|
|
96
|
+
// ❌ Open CORS
|
|
97
97
|
app.use(cors({ origin: '*' }));
|
|
98
98
|
|
|
99
|
-
// ✅ CORS
|
|
99
|
+
// ✅ Restricted CORS
|
|
100
100
|
app.use(cors({ origin: process.env.ALLOWED_ORIGINS?.split(',') }));
|
|
101
101
|
```
|
|
102
102
|
|
|
103
103
|
---
|
|
104
104
|
|
|
105
|
-
## 6.
|
|
105
|
+
## 6. Input Validation
|
|
106
106
|
|
|
107
|
-
- [ ]
|
|
108
|
-
- [ ]
|
|
109
|
-
- [ ]
|
|
110
|
-
- [ ]
|
|
107
|
+
- [ ] All form inputs are validated on the backend (not only on the frontend)
|
|
108
|
+
- [ ] File uploads validate type, size, and content
|
|
109
|
+
- [ ] Pagination has maximum limits (doesn't allow `limit=999999`)
|
|
110
|
+
- [ ] Numeric fields validate range (doesn't accept negatives when it shouldn't)
|
|
111
111
|
|
|
112
112
|
---
|
|
113
113
|
|
|
114
|
-
##
|
|
114
|
+
## Security Issue Classification
|
|
115
115
|
|
|
116
|
-
| Issue |
|
|
116
|
+
| Issue | Severity |
|
|
117
117
|
|:---|:---|
|
|
118
|
-
| SQL/XSS/Command Injection | 🔴
|
|
119
|
-
| IDOR (
|
|
120
|
-
|
|
|
121
|
-
| Secrets hardcoded
|
|
122
|
-
| Token
|
|
123
|
-
| CORS `*`
|
|
124
|
-
|
|
|
125
|
-
|
|
|
126
|
-
| Stack trace
|
|
127
|
-
|
|
|
128
|
-
|
|
|
118
|
+
| SQL/XSS/Command Injection | 🔴 Critical |
|
|
119
|
+
| IDOR (access to other users' data) | 🔴 Critical |
|
|
120
|
+
| Plaintext password / weak hash | 🔴 Critical |
|
|
121
|
+
| Secrets hardcoded in code | 🔴 Critical |
|
|
122
|
+
| Token without expiration | 🔴 Critical |
|
|
123
|
+
| CORS `*` in production | 🟡 Medium |
|
|
124
|
+
| Missing rate limiting | 🟡 Medium |
|
|
125
|
+
| Missing security headers | 🟡 Medium |
|
|
126
|
+
| Stack trace in error response | 🟡 Medium |
|
|
127
|
+
| Frontend-only validation | 🟡 Medium |
|
|
128
|
+
| Missing pagination limit | 🟢 Low |
|
|
129
129
|
|
|
130
130
|
> [!IMPORTANT]
|
|
131
|
-
> **
|
|
131
|
+
> **Every security issue classified as Critical MUST be fixed immediately.** Never move to backlog.
|