530 lines
24 KiB
Markdown
530 lines
24 KiB
Markdown
# Prompt: ตรวจสอบการแสดงผลของระบบเทียบกับ Permission โดยยังไม่แก้ไขโค้ด
|
|
|
|
## เป้าหมาย
|
|
|
|
ให้ตรวจสอบระบบทั้งหมดว่า การแสดงผลของหน้า เมนู ปุ่ม ข้อมูล ฟิลด์ และ Action ต่าง ๆ สอดคล้องกับ Permission และ Role ที่ระบบกำหนดไว้จริงหรือไม่
|
|
|
|
งานนี้เป็น **Audit / Review เท่านั้น**
|
|
ห้ามแก้ไขโค้ด ห้ามเปลี่ยน Permission และห้ามปรับพฤติกรรมของระบบในขั้นตอนนี้
|
|
|
|
ผลลัพธ์ที่ต้องการคือรายงานปัญหา พร้อมหลักฐาน ตำแหน่งโค้ด ผลกระทบ และแนวทางแก้ไขสำหรับนำไปดำเนินการในขั้นตอนถัดไป
|
|
|
|
---
|
|
|
|
## ขอบเขตการตรวจสอบ
|
|
|
|
ตรวจสอบทั้งระบบ ครอบคลุมอย่างน้อยดังนี้
|
|
|
|
- Sidebar และ Navigation
|
|
- Dashboard
|
|
- หน้ารายการ
|
|
- หน้ารายละเอียด
|
|
- หน้าสร้างข้อมูล
|
|
- หน้าแก้ไขข้อมูล
|
|
- Dialog, Modal, Drawer, Sheet และ Dropdown Menu
|
|
- ปุ่ม Action ในตาราง
|
|
- ปุ่มสร้าง แก้ไข ลบ ส่งตรวจสอบ อนุมัติ ปฏิเสธ ส่งกลับ และเผยแพร่
|
|
- ข้อมูลภายใน Card, Table, Form และ Detail Section
|
|
- หมายเหตุการตรวจสอบ
|
|
- ประวัติการอนุมัติ
|
|
- Audit Log
|
|
- API Route
|
|
- Server Action
|
|
- Query และ Service Layer
|
|
- Middleware
|
|
- Route Guard
|
|
- Permission Helper
|
|
- Role Guard
|
|
- Component Guard
|
|
- Backend Authorization
|
|
|
|
ให้ตรวจสอบทุกโมดูลที่มีอยู่ในระบบ เช่น
|
|
|
|
- ผู้ใช้งานและพนักงาน
|
|
- ประวัติการอบรม
|
|
- บทเรียนออนไลน์
|
|
- ประกาศ
|
|
- การแจ้งเตือน
|
|
- นโยบาย
|
|
- การอนุมัติ
|
|
- รายงาน
|
|
- ตั้งค่าระบบ
|
|
- Audit Log
|
|
- โมดูลอื่น ๆ ที่ค้นพบในโครงการ
|
|
|
|
---
|
|
|
|
## Role และ Permission
|
|
|
|
ให้ค้นหา Role และ Permission จากโค้ดจริงก่อนเริ่มตรวจสอบ เช่น
|
|
|
|
- User / Employee
|
|
- Admin
|
|
- HRD Staff
|
|
- HRD Manager
|
|
- IT Admin
|
|
- Reviewer
|
|
- Approver
|
|
- Role อื่น ๆ ที่ระบบมีอยู่จริง
|
|
|
|
ห้ามสมมติชื่อ Role หรือ Permission จากเอกสารเพียงอย่างเดียว
|
|
|
|
ให้ค้นหาแหล่งกำหนด Permission ทั้งหมด เช่น
|
|
|
|
- Enum
|
|
- Constant
|
|
- Permission Matrix
|
|
- Database Schema
|
|
- Seed Data
|
|
- Middleware
|
|
- Session
|
|
- JWT
|
|
- Auth.js callback
|
|
- Route configuration
|
|
- Sidebar configuration
|
|
- Helper function เช่น `hasPermission`, `canAccess`, `canManage`
|
|
- Server-side authorization
|
|
- Client-side conditional rendering
|
|
|
|
จากนั้นจัดทำ Permission Matrix ที่อ้างอิงจากโค้ดจริงก่อนตรวจสอบหน้าจอ
|
|
|
|
---
|
|
|
|
## หลักการตรวจสอบ
|
|
|
|
การตรวจสอบต้องครอบคลุมทั้งสองระดับ
|
|
|
|
### 1. การแสดงผลฝั่ง Client
|
|
|
|
ตรวจสอบว่า Role หรือ Permission แต่ละประเภทเห็นเฉพาะสิ่งที่ควรเห็นหรือไม่ เช่น
|
|
|
|
- เมนูที่ไม่มีสิทธิ์ถูกซ่อนหรือไม่
|
|
- ปุ่มที่ไม่มีสิทธิ์ถูกซ่อนหรือ Disable อย่างถูกต้องหรือไม่
|
|
- ข้อมูลภายในหน้ารายละเอียดถูกกรองตามสิทธิ์หรือไม่
|
|
- ฟิลด์ภายใน Form แสดงตาม Role หรือ Status หรือไม่
|
|
- Action Menu แสดงเฉพาะ Action ที่ทำได้จริงหรือไม่
|
|
- ข้อความ หมายเหตุ และประวัติภายในระบบเปิดเผยเกินสิทธิ์หรือไม่
|
|
|
|
### 2. การบังคับสิทธิ์ฝั่ง Server
|
|
|
|
ห้ามสรุปว่าระบบปลอดภัยเพียงเพราะซ่อนปุ่มหรือซ่อนเมนูแล้ว
|
|
|
|
ต้องตรวจสอบด้วยว่า ผู้ไม่มีสิทธิ์สามารถเรียกใช้งานผ่าน URL, API, Server Action หรือ Request โดยตรงได้หรือไม่ เช่น
|
|
|
|
- เปิด URL โดยตรง
|
|
- เรียก API โดยตรง
|
|
- ส่ง Request จาก DevTools
|
|
- แก้ไข Parameter
|
|
- เปลี่ยน Record ID
|
|
- เรียก Server Action โดยไม่ผ่าน UI
|
|
- เข้าถึงข้อมูลของผู้ใช้งานรายอื่น
|
|
- แก้ไขข้อมูลของผู้ใช้งานรายอื่น
|
|
- เรียก Action ที่ UI ซ่อนไว้
|
|
|
|
---
|
|
|
|
## ประเด็นสำคัญที่ต้องตรวจสอบ
|
|
|
|
### A. เมนูและเส้นทาง
|
|
|
|
ตรวจสอบว่า
|
|
|
|
- Sidebar แสดงเมนูตาม Permission
|
|
- ผู้ไม่มีสิทธิ์ไม่สามารถเข้าหน้าผ่าน URL โดยตรง
|
|
- Route Guard และ Middleware ใช้เงื่อนไขเดียวกับ Sidebar
|
|
- ไม่มีหน้าที่ซ่อนเมนูแต่ยังเข้าผ่าน URL ได้
|
|
- ไม่มีหน้าที่ Sidebar แสดงให้เห็น แต่เข้าใช้งานจริงไม่ได้
|
|
- Redirect และ Forbidden Page ทำงานสม่ำเสมอ
|
|
|
|
### B. ปุ่มและ Action
|
|
|
|
ตรวจสอบทุก Action เช่น
|
|
|
|
- สร้าง
|
|
- บันทึกฉบับร่าง
|
|
- แก้ไข
|
|
- ลบ
|
|
- ส่งตรวจสอบ
|
|
- อนุมัติ
|
|
- ปฏิเสธ
|
|
- ส่งกลับแก้ไข
|
|
- เผยแพร่
|
|
- ยกเลิกเผยแพร่
|
|
- ปักหมุด
|
|
- นำเข้า
|
|
- ส่งออก
|
|
- ดาวน์โหลด
|
|
- จัดการ Permission
|
|
|
|
ตรวจสอบว่า
|
|
|
|
- ปุ่มแสดงเฉพาะ Role ที่มีสิทธิ์
|
|
- Action สอดคล้องกับสถานะข้อมูล
|
|
- Backend ตรวจ Permission ซ้ำ
|
|
- ไม่สามารถข้าม Workflow ได้
|
|
- ไม่มี Action ที่ UI แสดงแต่ Backend ปฏิเสธโดยไม่ตั้งใจ
|
|
- ไม่มี Action ที่ UI ซ่อน แต่ Backend ยังอนุญาต
|
|
|
|
### C. การแสดงข้อมูลละเอียดอ่อน
|
|
|
|
ตรวจสอบข้อมูลที่อาจไม่ควรแสดงแก่ผู้ใช้งานทั่วไป เช่น
|
|
|
|
- หมายเหตุการตรวจสอบ
|
|
- เหตุผลการปฏิเสธ
|
|
- Internal Comment
|
|
- Reviewer Note
|
|
- Approval Note
|
|
- Audit Log
|
|
- ชื่อผู้อนุมัติ
|
|
- ประวัติการแก้ไข
|
|
- Metadata ภายใน
|
|
- Permission หรือ Role ภายใน
|
|
- ข้อมูลพนักงานรายอื่น
|
|
- ข้อมูลสถานะภายใน Workflow
|
|
|
|
ให้ตรวจสอบเป็นพิเศษว่า หน้าผู้ใช้งานทั่วไปมีการแสดง “หมายเหตุการตรวจสอบ” หรือข้อมูลภายในของเจ้าหน้าที่โดยไม่ตั้งใจหรือไม่
|
|
|
|
### D. Ownership และขอบเขตข้อมูล
|
|
|
|
ตรวจสอบว่า
|
|
|
|
- ผู้ใช้งานทั่วไปเห็นเฉพาะข้อมูลของตนเอง
|
|
- เจ้าหน้าที่เห็นข้อมูลตามบริษัท ฝ่าย หรือขอบเขตที่กำหนด
|
|
- Reviewer และ Approver เห็นเฉพาะรายการที่เกี่ยวข้อง
|
|
- Admin เห็นข้อมูลทั้งหมดตามที่ออกแบบ
|
|
- การเปลี่ยน ID ใน URL หรือ Request ไม่ทำให้เข้าถึงข้อมูลของผู้อื่น
|
|
- Query มีเงื่อนไขกรองตาม Ownership และ Permission
|
|
- การ Export ไม่ส่งออกข้อมูลเกินสิทธิ์
|
|
- Search และ Filter ไม่สามารถใช้ดึงข้อมูลนอกขอบเขต
|
|
|
|
### E. Workflow และ Status
|
|
|
|
ตรวจสอบ Permission ร่วมกับสถานะ เช่น
|
|
|
|
- Draft
|
|
- Pending
|
|
- Submitted
|
|
- Approved
|
|
- Rejected
|
|
- Returned
|
|
- Published
|
|
- Archived
|
|
- Cancelled
|
|
- สถานะอื่นที่มีอยู่จริง
|
|
|
|
ตัวอย่างการตรวจสอบ
|
|
|
|
- เจ้าของรายการแก้ไขได้เฉพาะ Draft หรือ Returned หรือไม่
|
|
- เมื่อส่งตรวจสอบแล้ว ผู้ใช้งานยังแก้ไขได้หรือไม่
|
|
- ผู้ใช้งานเห็นรายการ Rejected หรือ Returned ตามที่กำหนดหรือไม่
|
|
- Reviewer เห็นรายการที่ต้องตรวจสอบจริงหรือไม่
|
|
- Approver สามารถอนุมัติรายการที่ยังไม่ถึงขั้นตนเองหรือไม่
|
|
- รายการ Published แสดงแก่ผู้ใช้งานตามเงื่อนไขหรือไม่
|
|
- การแสดงปุ่มสอดคล้องกับ Permission และ Status พร้อมกันหรือไม่
|
|
|
|
---
|
|
|
|
## วิธีดำเนินการ
|
|
|
|
### ขั้นตอนที่ 1: สำรวจโครงสร้าง Permission
|
|
|
|
ค้นหาและสรุป
|
|
|
|
- Role ทั้งหมด
|
|
- Permission ทั้งหมด
|
|
- Mapping ระหว่าง Role และ Permission
|
|
- Permission Helper ทั้งหมด
|
|
- Route Guard
|
|
- API Guard
|
|
- Server Action Guard
|
|
- Ownership Rule
|
|
- Status Rule
|
|
|
|
### ขั้นตอนที่ 2: จัดทำ Permission Matrix
|
|
|
|
จัดทำตารางในรูปแบบประมาณนี้
|
|
|
|
| Module | Page / Action | User | Staff | Manager | Admin | เงื่อนไขเพิ่มเติม |
|
|
| -------------- | -------------------- | ---------: | ----: | ------: | ------: | ----------------------- |
|
|
| Online Lessons | ดูรายการเผยแพร่ | Yes | Yes | Yes | Yes | เฉพาะ Published |
|
|
| Online Lessons | ดูหมายเหตุการตรวจสอบ | No | Yes | Yes | Yes | ผู้ใช้งานทั่วไปห้ามเห็น |
|
|
| Online Lessons | แก้ไข Draft | Owner only | Yes | Yes | Yes | ตาม Ownership |
|
|
| Online Lessons | อนุมัติ | No | No | Yes | ตามระบบ | Pending เท่านั้น |
|
|
|
|
ให้ใช้ Role จริงจากระบบแทนตัวอย่างข้างต้น
|
|
|
|
### ขั้นตอนที่ 3: ตรวจสอบ UI กับ Matrix
|
|
|
|
ตรวจสอบทุกหน้าและ Component ว่า
|
|
|
|
- Render Condition ถูกต้องหรือไม่
|
|
- ใช้ Permission Helper มาตรฐานหรือไม่
|
|
- มีการ Hardcode Role หรือไม่
|
|
- มี Logic ซ้ำซ้อนหรือขัดแย้งกันหรือไม่
|
|
- มีการตรวจเฉพาะ Role แต่ไม่ตรวจ Permission หรือไม่
|
|
- มีการตรวจเฉพาะ Status แต่ไม่ตรวจ Role หรือไม่
|
|
- มีการซ่อนด้วย CSS โดยไม่ได้หยุดการ Render หรือไม่
|
|
|
|
### ขั้นตอนที่ 4: ตรวจสอบ Backend กับ Matrix
|
|
|
|
ตรวจสอบ
|
|
|
|
- API Route
|
|
- Route Handler
|
|
- Server Action
|
|
- Service Function
|
|
- Repository
|
|
- Database Query
|
|
|
|
ให้ยืนยันว่าแต่ละ Action ตรวจสอบครบทั้ง
|
|
|
|
1. Authentication
|
|
2. Role หรือ Permission
|
|
3. Ownership หรือ Data Scope
|
|
4. Record Status
|
|
5. Input Validation
|
|
|
|
### ขั้นตอนที่ 5: ตรวจหาความไม่สอดคล้อง
|
|
|
|
จัดประเภทปัญหาอย่างน้อยดังนี้
|
|
|
|
- UI แสดงเกินสิทธิ์
|
|
- UI ซ่อนผิด แม้มีสิทธิ์
|
|
- เข้าผ่าน URL โดยตรงได้
|
|
- API ไม่มี Authorization
|
|
- Server Action ไม่มี Authorization
|
|
- Data Query ไม่กรอง Ownership
|
|
- Export ข้อมูลเกินสิทธิ์
|
|
- Role และ Permission Logic ไม่ตรงกัน
|
|
- Permission Logic กระจายหลายจุด
|
|
- Hardcoded Role
|
|
- Status Guard ไม่ครบ
|
|
- ข้อมูลภายในรั่วไปยังผู้ใช้งานทั่วไป
|
|
- Client และ Server ใช้เงื่อนไขต่างกัน
|
|
- Permission Matrix ไม่ตรงกับการทำงานจริง
|
|
|
|
---
|
|
|
|
## สิ่งที่ห้ามทำ
|
|
|
|
- ห้ามแก้ไขไฟล์ใด ๆ
|
|
- ห้าม Refactor
|
|
- ห้ามเปลี่ยน Permission
|
|
- ห้ามเปลี่ยน Role
|
|
- ห้ามแก้ Middleware
|
|
- ห้ามแก้ Component
|
|
- ห้ามแก้ API
|
|
- ห้ามแก้ Server Action
|
|
- ห้ามแก้ Database Schema
|
|
- ห้ามสร้าง Migration
|
|
- ห้ามรันคำสั่งที่แก้ไขข้อมูล
|
|
- ห้ามลบหรือเพิ่ม Dependency
|
|
- ห้าม Commit
|
|
- ห้าม Push
|
|
- ห้ามสรุปจากชื่อไฟล์โดยไม่ได้อ่าน Logic จริง
|
|
|
|
อนุญาตเฉพาะการอ่าน วิเคราะห์ ค้นหา และจัดทำรายงาน
|
|
|
|
---
|
|
|
|
## รูปแบบรายงานที่ต้องส่งมอบ
|
|
|
|
สร้างไฟล์
|
|
|
|
```text
|
|
permission-display-audit.md
|
|
```
|
|
|
|
โดยมีโครงสร้างดังนี้
|
|
|
|
# Permission and Display Audit Report
|
|
|
|
## 1. Executive Summary
|
|
|
|
สรุปภาพรวมว่า
|
|
|
|
- ระบบสอดคล้องกับ Permission มากน้อยเพียงใด
|
|
- พบ Critical, High, Medium และ Low กี่รายการ
|
|
- โมดูลใดมีความเสี่ยงสูง
|
|
- มีข้อมูลใดถูกแสดงเกินสิทธิ์หรือไม่
|
|
- Backend บังคับ Permission ครบถ้วนหรือไม่
|
|
|
|
## 2. Roles and Permissions Discovered
|
|
|
|
ระบุ
|
|
|
|
- Role ที่พบ
|
|
- Permission ที่พบ
|
|
- แหล่งที่กำหนด
|
|
- File path
|
|
- Logic โดยย่อ
|
|
|
|
## 3. Permission Matrix
|
|
|
|
ตารางสิทธิ์ของทุกโมดูล ทุกหน้า และทุก Action
|
|
|
|
## 4. Route and Navigation Audit
|
|
|
|
ตาราง
|
|
|
|
| ID | Route | Menu Permission | Route Guard | Direct URL Result | Status |
|
|
| --- | ----- | --------------- | ----------- | ----------------- | ------ |
|
|
|
|
## 5. UI Display Audit
|
|
|
|
ตาราง
|
|
|
|
| ID | Module | Page / Component | Element | Expected | Actual | Severity | Evidence |
|
|
| --- | ------ | ---------------- | ------- | -------- | ------ | -------- | -------- |
|
|
|
|
## 6. Backend Authorization Audit
|
|
|
|
ตาราง
|
|
|
|
| ID | Endpoint / Action | Authentication | Permission | Ownership | Status Guard | Result |
|
|
| --- | ----------------- | -------------- | ---------- | --------- | ------------ | ------ |
|
|
|
|
## 7. Findings
|
|
|
|
สำหรับแต่ละปัญหา ให้ใช้รูปแบบ
|
|
|
|
### PERM-001: ชื่อปัญหา
|
|
|
|
- Severity:
|
|
- Module:
|
|
- Affected roles:
|
|
- Expected behavior:
|
|
- Actual behavior:
|
|
- Security or business impact:
|
|
- Root cause:
|
|
- Evidence:
|
|
- File path:
|
|
- Line or code reference:
|
|
- Reproduction steps:
|
|
- Recommended remediation:
|
|
- Related findings:
|
|
|
|
## 8. Role-based Test Scenarios
|
|
|
|
จัดทำกรณีทดสอบสำหรับแต่ละ Role เช่น
|
|
|
|
| Test ID | Role | Page | Action | Expected Result |
|
|
| ------- | ---- | ---- | ------ | --------------- |
|
|
|
|
ต้องครอบคลุมอย่างน้อย
|
|
|
|
- เปิดเมนู
|
|
- เปิด URL โดยตรง
|
|
- ดูรายการ
|
|
- ดูรายละเอียด
|
|
- สร้าง
|
|
- แก้ไข
|
|
- ลบ
|
|
- ส่งตรวจสอบ
|
|
- อนุมัติ
|
|
- ปฏิเสธ
|
|
- ส่งกลับ
|
|
- Export
|
|
- เข้าถึงข้อมูลของผู้อื่น
|
|
- เปลี่ยน Record ID
|
|
- เรียก API โดยตรง
|
|
|
|
## 9. Prioritized Remediation Plan
|
|
|
|
จัดลำดับแนวทางแก้ไข โดยยังไม่แก้โค้ด
|
|
|
|
### Priority 0 — Critical Security
|
|
|
|
ปัญหาที่ทำให้ผู้ไม่มีสิทธิ์เข้าถึงหรือแก้ไขข้อมูลได้
|
|
|
|
### Priority 1 — Permission Mismatch
|
|
|
|
UI และ Backend ใช้เงื่อนไขไม่ตรงกัน
|
|
|
|
### Priority 2 — Data Exposure
|
|
|
|
ข้อมูลภายในหรือหมายเหตุแสดงเกินสิทธิ์
|
|
|
|
### Priority 3 — Maintainability
|
|
|
|
Permission Logic ซ้ำซ้อน กระจาย หรือ Hardcode
|
|
|
|
## 10. Files Reviewed
|
|
|
|
ระบุไฟล์ทั้งหมดที่ตรวจสอบ พร้อมเหตุผลที่เกี่ยวข้อง
|
|
|
|
## 11. Files Not Reviewed or Limitations
|
|
|
|
ระบุส่วนที่ไม่สามารถตรวจสอบได้ พร้อมเหตุผลอย่างตรงไปตรงมา
|
|
|
|
## 12. Final Assessment
|
|
|
|
สรุปว่า
|
|
|
|
- ระบบพร้อมใช้งานในด้าน Permission หรือไม่
|
|
- ประเด็นใดต้องแก้ก่อน Production
|
|
- ประเด็นใดสามารถวางแผนแก้ภายหลัง
|
|
- ความเสี่ยงที่ยังเหลืออยู่
|
|
|
|
---
|
|
|
|
## ระดับความรุนแรง
|
|
|
|
### Critical
|
|
|
|
- ผู้ไม่มีสิทธิ์เข้าถึงหรือแก้ไขข้อมูลสำคัญได้
|
|
- API หรือ Server Action ไม่มี Authorization
|
|
- เปลี่ยน Record ID แล้วเข้าถึงข้อมูลของผู้อื่นได้
|
|
- สามารถข้าม Workflow หรืออนุมัติแทน Role อื่นได้
|
|
|
|
### High
|
|
|
|
- UI หรือ Route แสดงข้อมูลละเอียดอ่อนเกินสิทธิ์
|
|
- Permission ระหว่าง Client และ Server ไม่ตรงกัน
|
|
- Ownership Rule ไม่ครบ
|
|
- Export ข้อมูลเกินขอบเขต
|
|
|
|
### Medium
|
|
|
|
- ปุ่มแสดงหรือซ่อนผิด
|
|
- Status และ Permission ไม่สัมพันธ์กัน
|
|
- ผู้มีสิทธิ์ใช้งานไม่ได้ตามปกติ
|
|
- Logic ซ้ำซ้อนและเสี่ยงเกิดความไม่สอดคล้อง
|
|
|
|
### Low
|
|
|
|
- ข้อความไม่เหมาะสมกับ Role
|
|
- UI สื่อความหมาย Permission ไม่ชัด
|
|
- Code Quality หรือ Maintainability ที่ยังไม่ทำให้สิทธิ์ผิดทันที
|
|
|
|
---
|
|
|
|
## เกณฑ์การตรวจสอบเพิ่มเติม
|
|
|
|
- อ้างอิงจากโค้ดจริง ไม่อ้างอิงเฉพาะ Requirement
|
|
- ทุก Finding ต้องมี File path หรือหลักฐาน
|
|
- แยก Expected กับ Actual ให้ชัดเจน
|
|
- ห้ามรายงานเป็นข้อสันนิษฐานโดยไม่มีหลักฐาน
|
|
- เมื่อไม่แน่ใจให้ระบุว่า “ต้องยืนยันเพิ่มเติม”
|
|
- ตรวจสอบทั้ง Client และ Server เสมอ
|
|
- ให้ความสำคัญกับ Security มากกว่าการซ่อน UI
|
|
- ห้ามใช้คำว่า “ผ่าน” หากตรวจเพียงฝั่งหน้าเว็บ
|
|
- ตรวจสอบว่าการใช้ `role`, `permission`, `status` และ `ownership` เป็นมาตรฐานเดียวกันทั้งระบบหรือไม่
|
|
|
|
---
|
|
|
|
## คำสั่งสุดท้าย
|
|
|
|
เริ่มจากสำรวจโครงสร้างโปรเจกต์และ Permission ทั้งหมดก่อน จากนั้นตรวจสอบการแสดงผลและการเข้าถึงของระบบทุกโมดูล
|
|
|
|
งานนี้ให้ดำเนินการเฉพาะการตรวจสอบและจัดทำรายงานเท่านั้น ห้ามแก้ไขโค้ดทุกกรณี
|
|
|
|
เมื่อเสร็จแล้วให้สรุปในข้อความตอบกลับว่า
|
|
|
|
1. พบปัญหาทั้งหมดกี่รายการ แยกตาม Severity
|
|
2. โมดูลใดมีความเสี่ยงสูงที่สุด
|
|
3. มีกรณีข้อมูลแสดงเกินสิทธิ์หรือไม่
|
|
4. มี API หรือ Server Action ที่ไม่มี Authorization หรือไม่
|
|
5. สร้างไฟล์รายงานไว้ที่ตำแหน่งใด
|
|
6. ยืนยันว่าไม่มีการแก้ไขโค้ดหรือข้อมูลในระบบ
|