Security Testing

Part of: MPAC SmartPOS Cloud Platform - Product RequirementsVersion: 2.0 Last Updated: 2026-01-28

Overview

This document defines security testing procedures, tools, and compliance requirements for the MPAC platform. Security testing encompasses automated vulnerability scanning, manual penetration testing, and regulatory compliance audits to ensure the platform meets PCI DSS Level 1, SOC 2 Type II, and GDPR requirements. The testing strategy includes continuous automated scanning in CI/CD pipelines, annual third-party penetration tests, and regular compliance audits to protect payment data and customer information.

Automated Security Scans
Penetration Testing
Compliance Audits

Automated Security Scans

Purpose: Continuous security validation integrated into development and deployment workflows.

Dependency Vulnerability Scanning

OWASP Dependency Check (Weekly):

bash

# Run dependency check for Python projects
cd mpac-smartpos/svc-portal
uv run safety check --json > security-report.json

# Run dependency check for Go projects
cd mpac-smartpos/svc-smarttab
nancy sleuth --exclude-vulnerability-file .nancy-ignore

# Run dependency check for Node.js projects
cd mpac-frontend
pnpm audit --audit-level=high --json > audit-report.json

Configuration:

yaml

# .github/workflows/security-scan.yml
name: Security Scanning

on:
  schedule:
    - cron: '0 2 * * 1'  # Weekly on Monday at 2am
  pull_request:
    branches: [main, develop]

jobs:
  dependency-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Run Snyk scan
        uses: snyk/actions/python@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          command: test
          args: --severity-threshold=high --fail-on=all

Severity Response:

Critical: Block deployment, immediate fix required
High: Create P1 ticket, fix within 24 hours
Medium: Create P2 ticket, fix within 1 week
Low: Create P3 ticket, fix in next sprint

Snyk Vulnerability Scanning (On Pull Request)

Integration:

yaml

# Snyk configuration
version: v1.22.0
language-settings:
  python:
    targetFile: requirements.txt
  javascript:
    targetFile: package.json
  go:
    targetFile: go.mod

exclude:
  global:
    - test/**
    - docs/**

Automated Actions:

Run on every pull request to main and develop
Block PR merge if critical vulnerabilities detected
Auto-create GitHub issues for high/critical findings
Weekly scheduled scans of all branches

Container Image Scanning (Trivy)

Scan Docker Images:

bash

# Scan backend images
trivy image mpac/svc-portal:latest \
  --severity HIGH,CRITICAL \
  --exit-code 1 \
  --no-progress

trivy image mpac/svc-smarttab:latest \
  --severity HIGH,CRITICAL \
  --exit-code 1

trivy image mpac/mpac-pgw:latest \
  --severity HIGH,CRITICAL \
  --exit-code 1

# Scan filesystem for secrets
trivy fs --scanners secret,config mpac-smartpos/

CI/CD Integration:

yaml

# .github/workflows/docker-build.yml
- name: Scan Docker image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'mpac/svc-portal:${{ github.sha }}'
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'

- name: Upload Trivy results to GitHub Security
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: 'trivy-results.sarif'

Static Application Security Testing (SAST)

Bandit (Python - svc-portal):

bash

# Run Bandit security linter
cd mpac-smartpos/svc-portal
uv run bandit -r mpac/ -f json -o bandit-report.json

# Check for common security issues:
# - SQL injection vulnerabilities
# - Hardcoded passwords/secrets
# - Use of insecure functions (eval, exec, pickle)
# - Weak cryptography
# - Command injection risks

Example Bandit Configuration:

yaml

# .bandit
exclude_dirs:
  - /tests/
  - /migrations/

tests:
  - B201  # flask_debug_true
  - B501  # request_with_no_cert_validation
  - B506  # yaml_load
  - B601  # paramiko_calls
  - B602  # shell_injection
  - B608  # hardcoded_sql_expressions

gosec (Go - svc-smarttab, mpac-pgw):

bash

# Run gosec security scanner
cd mpac-smartpos/svc-smarttab
gosec -fmt=json -out=gosec-report.json ./...

# Common checks:
# - SQL injection (G201, G202)
# - Command injection (G204)
# - Weak crypto (G401, G402)
# - File inclusion vulnerabilities (G304)
# - Unsafe reflect usage (G203)

Example gosec Configuration:

json

{
  "exclude": ["G104"],  // Ignore unhandled errors (handled by linter)
  "exclude-dirs": ["tests", "mocks"],
  "severity": "medium"
}

ESLint Security Plugin (Frontend):

bash

# Run ESLint with security rules
cd mpac-frontend
pnpm eslint . --ext .ts,.tsx \
  --plugin security \
  --rule 'security/detect-object-injection: error'

Penetration Testing

Purpose: Manual security assessment by qualified security professionals.

Annual Third-Party Penetration Test

Scope:

Full application stack (frontend, backend APIs, databases)
Infrastructure (AWS/cloud environment)
Network security
Physical security (data center/office if applicable)

Testing Methodology:

OWASP Top 10 (2021) coverage
PTES (Penetration Testing Execution Standard)
Black box, grey box, and white box testing phases
Simulated real-world attack scenarios

Timeline:

Week 1-2: Reconnaissance and information gathering
Week 3-4: Vulnerability assessment and exploitation
Week 5:   Post-exploitation and privilege escalation
Week 6:   Report generation and remediation planning
Week 7-8: Remediation and re-testing

Focus Areas

1. Authentication and Authorization Bypass

Test JWT token manipulation and forgery
Session fixation and hijacking
OAuth2 flow vulnerabilities
Device authentication bypass attempts
Impersonation token validation
RBAC enforcement at API level

Attack Scenarios:

- Can a Store Manager access PSP Admin endpoints?
- Can device A obtain device B's authentication token?
- Does token expiry enforcement work correctly?
- Can expired refresh tokens be reused?
- Is MFA bypass possible through race conditions?

2. SQL Injection

Parameterized query validation
ORM injection attempts (SQLAlchemy, GORM)
Stored procedure injection
Second-order SQL injection
NoSQL injection (if applicable)

Test Vectors:

sql

-- Test in order search endpoint
GET /orders?search='; DROP TABLE orders; --
GET /orders?search=' OR '1'='1
GET /orders?search=' UNION SELECT * FROM users --

-- Test in JSON payloads
POST /orders
{"store_id": "123' OR '1'='1", "items": []}

3. Cross-Site Scripting (XSS)

Reflected XSS in search and error messages
Stored XSS in user-generated content (product names, notes)
DOM-based XSS in frontend React components
Content Security Policy (CSP) validation

Test Vectors:

html

<!-- Test in product name field -->
<script>alert('XSS')</script>
<img src=x onerror=alert('XSS')>
<svg onload=alert('XSS')>

<!-- Test in order notes -->
<iframe src="javascript:alert('XSS')">

4. Insecure Direct Object References (IDOR)

Order ID enumeration
Bill ID access control
User profile access
Payment transaction access
Settlement report access

Test Scenarios:

Scenario: Access other merchant's orders
- Login as Merchant A (ID: 123)
- Obtain order from Merchant B (ID: 456)
- Try accessing: GET /orders/{merchant_b_order_id}
- Expected: 403 Forbidden or 404 Not Found
- If 200 OK returned: IDOR vulnerability confirmed

5. Payment Data Exposure

PAN (Primary Account Number) masking
CVV never stored
Card token security
Payment provider credentials protection
Webhook authentication

Test Cases:

- Can full card numbers be retrieved via API?
- Are payment tokens predictable or sequential?
- Is payment data logged in application logs?
- Are database backups encrypted?
- Can payment webhooks be spoofed?

6. API Rate Limit Bypass

Test rate limiting enforcement (1000/min per merchant)
Distributed request bypass attempts
Header manipulation to evade rate limiting
Token bucket algorithm testing

Attack Vectors:

bash

# Test rate limit enforcement
for i in {1..1100}; do
  curl -H "Authorization: Bearer $TOKEN" \
       https://api.mpac-cloud.com/orders &
done

# Test with rotated IP addresses
# Test with multiple API keys
# Test with connection reuse vs new connections

Compliance Audits

Purpose: Ensure regulatory compliance for payment processing and data protection.

PCI DSS Level 1 Audit (Annual)

Requirements Covered:

Build and Maintain Secure Network:
- Firewall configuration review
- Vendor-supplied defaults changed
- Encryption for cardholder data transmission
Protect Cardholder Data:
- Data retention policies (90 days max)
- PAN masking (only last 4 digits visible)
- Cryptographic key management (AWS KMS)
Maintain Vulnerability Management:
- Anti-virus on all systems
- Secure development lifecycle
- Regular security patching
Implement Strong Access Control:
- Unique user IDs for all personnel
- MFA for admin access
- Physical access controls
Monitor and Test Networks:
- Audit logging of all cardholder data access
- Log retention for 1 year
- Quarterly internal security scans
- Annual penetration tests
Maintain Information Security Policy:
- Documented security policies
- Annual security awareness training
- Incident response plan

Audit Process:

Q1: Pre-audit preparation and self-assessment
Q2: External QSA (Qualified Security Assessor) engagement
Q3: Audit execution and findings remediation
Q4: Attestation of Compliance (AOC) submission

SOC 2 Type II Audit (Annual)

Trust Service Criteria:

Security: System protected against unauthorized access
Availability: System available for operation (99.95% SLA)
Processing Integrity: Processing complete, valid, accurate, timely
Confidentiality: Confidential information protected
Privacy: Personal information collected, used, retained, disclosed per policy

Audit Period:

Minimum 6-month observation period
Quarterly control testing
Annual audit report

Key Controls Validated:

Change management procedures
Access provisioning and de-provisioning
Encryption at rest and in transit
Backup and disaster recovery
Incident response procedures

Data Subject Rights:

Right to access (data export within 30 days)
Right to erasure ("right to be forgotten")
Right to rectification (data correction)
Right to data portability
Right to object to processing

Technical Measures:

python

# Example: Data subject access request (DSAR)
async def handle_dsar(user_id: str) -> DSARReport:
    """
    Generate comprehensive data report for user.
    Must complete within 30 days per GDPR.
    """
    return DSARReport(
        user_data=await get_user_data(user_id),
        orders=await get_user_orders(user_id),
        payments=await get_user_payments(user_id),
        audit_logs=await get_user_audit_logs(user_id),
        consent_history=await get_consent_history(user_id)
    )

Compliance Checklist:

[ ] Data processing agreement (DPA) with all third-party processors
[ ] Privacy policy published and accessible
[ ] Cookie consent mechanism implemented
[ ] Data breach notification procedure (72-hour requirement)
[ ] Data Protection Impact Assessment (DPIA) completed
[ ] Data retention policy documented and enforced
[ ] Cross-border data transfer mechanisms (Standard Contractual Clauses)