Israeli Appsec Scanner

Israeli AppSec Scanner

Security scanning and compliance guidance tailored for Israeli web applications. This skill covers the full spectrum of application security, from OWASP Top 10 verification to Israeli Privacy Protection Authority (PPA) compliance, with special attention to Hebrew/RTL-specific attack vectors.

OWASP Top 10 version note (2025-2026). The checklist below is keyed to OWASP Top 10 2021. OWASP Top 10 2025 was published and re-shaped the categories: A01 now subsumes SSRF (no separate A10:SSRF entry), A03 is the new Software Supply Chain Failures, A05 is now Injection (down from A03), A09 was renamed Security Logging and Alerting Failures, and a new A10 covers Mishandling of Exceptional Conditions. When auditing in 2026, treat the 2021 numbering below as a working scaffold and cross-walk findings to the 2025 list at https://owasp.org/Top10/2025/ before reporting.

OWASP Top 10 Checklist (Israeli Context)

Work through each category systematically. For each finding, note the severity (Critical/High/Medium/Low) and provide a remediation recommendation.

A01: Broken Access Control

• Verify all API endpoints enforce authentication (check Next.js middleware, NestJS guards)
• Confirm role-based access control covers admin, user, and anonymous roles
• Test that Hebrew URL paths cannot bypass route-based authorization
• Check for Insecure Direct Object References (IDOR) on user-facing resources
• Verify CORS configuration restricts origins to expected Israeli domains
• Ensure JWT tokens are validated server-side, not just client-side
• Test directory traversal with Hebrew-encoded path segments (%D7%90 etc.)

A02: Cryptographic Failures

• Verify TLS 1.2+ on all connections (Israeli hosting providers sometimes default to older versions)
• Check that passwords are hashed with bcrypt/argon2 (not MD5/SHA1)
• Confirm Israeli national ID numbers (teudat zehut) are encrypted at rest
• Verify credit card data is never stored locally (PCI DSS requirement)
• Check that Supabase service role keys are never exposed to the client
• Ensure Israeli payment gateway tokens (Cardcom, Tranzila) use secure storage

A03: Injection

• Test SQL injection with Hebrew text input ('; DROP TABLE -- with Hebrew characters)
• Verify parameterized queries for all database operations involving Hebrew text
• Check for NoSQL injection in MongoDB queries (common in Israeli startups using MEAN stack)
• Test command injection through file upload names containing Hebrew characters
• Verify LDAP injection protection if integrating with Israeli corporate directories
• Check for template injection in email templates with Hebrew content

A04: Insecure Design

• Verify rate limiting on Israeli SMS gateway endpoints (prevent OTP bombing)
• Check for business logic flaws in Israeli payment processing flows
• Ensure multi-step forms (common in Israeli government service integrations) maintain state securely
• Verify that Hebrew input length limits account for UTF-8 multi-byte characters

A05: Security Misconfiguration

• Check HTTP security headers (CSP, X-Frame-Options, HSTS)
• Verify error pages do not leak stack traces or Hebrew debug messages
• Confirm default credentials are changed on all services
• Check that Israeli cloud provider (AWS IL region, GCP) security groups are properly configured
• Verify Supabase Row Level Security (RLS) policies are enabled on all tables
• Ensure .env files with Israeli service credentials are in .gitignore

A06: Vulnerable and Outdated Components

• Run npm audit or pnpm audit and address critical/high findings
• Check for known vulnerabilities in Hebrew-specific libraries (hebrew-date, bidirectional text processors)
• Verify container base images are up to date (use trivy image)
• Check for outdated Israeli payment SDK versions

A07: Identification and Authentication Failures

• Verify Israeli phone number format validation (+972) in authentication flows
• Check that OTP codes for Israeli mobile numbers have appropriate expiry (5 minutes max)
• Test password policies accommodate Hebrew characters
• Verify session management after authentication with Israeli OAuth providers
• Check for credential stuffing protection on login endpoints

A08: Software and Data Integrity Failures

• Verify npm package integrity with lockfile validation
• Check CI/CD pipeline security (GitHub Actions, Vercel deployment hooks)
• Ensure third-party Israeli service webhooks are verified (signature validation)
• Verify Subresource Integrity (SRI) for external scripts

A09: Security Logging and Monitoring Failures

• Confirm authentication events are logged (login, logout, failed attempts)
• Verify logs capture Hebrew text correctly (UTF-8 encoding)
• Check that Israeli PPA-required audit trails are maintained for personal data access
• Ensure log storage complies with Israeli data retention requirements

A10: Server-Side Request Forgery (SSRF)

• Verify URL validation for user-supplied URLs (block internal network ranges)
• Check that Israeli government API integrations validate redirect URLs
• Test for SSRF through Hebrew-encoded URLs and IDN homograph attacks

Israeli Privacy Protection Authority (PPA) Compliance

Israel's Privacy Protection Law (1981, last major reform Amendment 13 in force August 14, 2025) and its regulations impose specific requirements on applications handling personal data of Israeli residents. Amendment 13 requires immediate notification of a serious security incident to the PPA, mandatory DPO triggers, expanded definitions of "personal information" and "sensitive data", a notification tier for databases with especially sensitive data on >100,000 individuals, and a statutory damages head added by Amendment 13 of up to NIS 10,000 / 10,000 ש"ח without proof of harm for notification and data-subject-rights breaches. Higher no-proof-of-harm ceilings under the older PPL statutory-damages provision are conditional, and the administrative fine tariff is set by a scaling model, so consult the PPA's Amendment 13 guide rather than quoting a figure from memory.

Database Registration (reformed by Amendment 13)

Amendment 13 (August 2025) repealed the old broad registration duty. The pre-2025 rule, which required registering any database with 10,000+ records, or sensitive data, or used for direct marketing, no longer applies. The current regime:

1. Registration is now required only for: (a) data brokers, meaning databases whose main purpose is collecting personal data to transfer to others as a business, where the database holds data on more than 10,000 individuals; and (b) public bodies. The 10,000 threshold survives only in the data-broker context, not as a general trigger.
2. Notification (not registration): a controller of a database holding "especially sensitive information" on more than 100,000 individuals must notify the PPA of identity, contact, and DPO details, within 30 days, even when registration is not required. This duty is residual: it applies to databases that are NOT already subject to registration, not in addition to it.
3. No annual renewal: the annual-renewal requirement is gone. A previously-registered database that no longer qualifies is not auto-removed; the controller must apply to be struck from the register.
4. Most ordinary consumer apps no longer need to register at all under the new regime, but still owe the full security, consent, and data-subject-rights duties below.

Data Protection Requirements

CHECKLIST: Israeli Privacy Protection Law Compliance

[ ] Consent: Obtain informed consent before collecting personal data
    - Consent must be specific, informed, and freely given
    - Hebrew consent text must be clear and understandable
    - Separate consent for different processing purposes

[ ] Purpose limitation: Use data only for the stated purpose
    - Document the purpose in your privacy policy (Hebrew + English)
    - Do not repurpose data without fresh consent

[ ] Data minimization: Collect only necessary data
    - Review each form field for necessity
    - Israeli ID numbers should only be collected when legally required

[ ] Security measures: Implement appropriate technical measures
    - Follow PPA's "Information Security Regulations" (2017)
    - Determine your security level first (three levels, plus an individually-managed
      carve-out). High level = a First Schedule (1)/(3) database with 100,000+ people
      or more than 100 authorized users. See references/israeli-privacy-law-guide.md
    - Audit every 24 months (medium and high), NOT annually (Regulation 16(a))
    - Risk survey and penetration test every 18 months, HIGH level only (Regulation 5)
    - Maintain access logs for at least 24 months

[ ] Data subject rights: Support access, correction, deletion requests
    - Respond within 30 days to data access requests
    - Provide data in a structured, machine-readable format
    - Hebrew language support for all data subject communications

[ ] Breach notification: Notify PPA and affected individuals
    - "Serious security incident" must be reported to PPA
    - Notification should be in Hebrew for Israeli residents
    - Document all incidents and remediation steps

Cross-Border Data Transfer

Israeli law restricts transfer of personal data outside Israel, under the Privacy Protection (Transfer of Data Abroad) Regulations, 2001.

Two things must BOTH be satisfied, and this is the most common compliance error.

(1) A lawful gateway. Either the destination country's law guarantees protection no lower than Israeli law (Regulation 1), or one of the Regulation 2 exceptions applies. The main ones:

• The data subject consented to the transfer
• The recipient is a corporation controlled by the transferring database owner, and has secured privacy protection after the transfer
• The recipient has undertaken by agreement to comply with the conditions for holding and using data that apply to a database in Israel
• The transfer is required under Israeli law, or the destination is a Council of Europe Convention 108 state or another state the Registrar has published as having a privacy authority

(2) A written undertaking from the recipient (Regulation 3). This applies to transfers under Regulation 1 OR Regulation 2, so it is NOT a fourth alternative you can skip by relying on consent. The database owner must obtain the recipient's written undertaking that the recipient takes sufficient measures to protect the data subjects' privacy AND that the data will not be passed on to anyone else, whether in that country or another.

Consent alone therefore does NOT authorise shipping personal data to a US SaaS vendor with no data-transfer agreement. Note also that "Standard Contractual Clauses" is GDPR terminology; the Israeli instrument is the Regulation 3 written undertaking, though an SCC-based DPA can carry it.

Common scenarios for Israeli apps:

• Cloud hosting on AWS/GCP: Ensure data processing agreement is in place
• Using US-based SaaS tools: Verify contractual safeguards
• Analytics services: Consider data anonymization before transfer

Dependency Scanning

npm/pnpm Audit

# Run vulnerability scan
pnpm audit

# Fix automatically where possible
pnpm audit --fix

# Generate detailed JSON report
pnpm audit --json > audit-report.json

# Check specific severity levels
pnpm audit --audit-level=high

Container Scanning with Trivy

Trivy supply-chain compromise (March 2026). GHSA-69fq-xp46-6x23 / CVE-2026-33634 (critical). On 19 Mar 2026 a malicious Trivy v0.69.4 release was published, 76 of 77 tags in aquasecurity/trivy-action were force-pushed to credential-stealing malware, and all 7 tags in aquasecurity/setup-trivy were replaced. On 22 Mar 2026 malicious v0.69.5 and v0.69.6 DockerHub images followed. Fixed versions per the advisory: trivy-action >= 0.35.0, setup-trivy >= 0.2.6; for the binary, v0.69.3 and earlier are unaffected and current stable is v0.74.0 (Aug 2026), so upgrade rather than pinning back. Pin GitHub Actions to a full commit SHA (not a floating @v0.x tag, which is what made this exploitable), reference images by digest, and rotate any secret exposed to a CI run during the window.

# Scan Docker image
trivy image your-app:latest

# Scan with severity filter
trivy image --severity HIGH,CRITICAL your-app:latest

# Scan filesystem (for local projects)
trivy fs --scanners vuln,secret,misconfig .

# Generate SARIF report for GitHub integration
trivy image --format sarif --output trivy-results.sarif your-app:latest

Python Dependency Scanning

# Using pip-audit
pip-audit

# With fix suggestions
pip-audit --fix --dry-run

# Scan requirements file
pip-audit -r requirements.txt

Snyk Integration

# Authenticate
snyk auth

# Test for vulnerabilities
snyk test

# Monitor project (continuous)
snyk monitor

# Test specific package
snyk test --package-manager=npm

Secrets Detection

Scanning for Israeli Service Credentials

Israeli applications commonly use service credentials that must never be committed to version control:

Israeli Payment Gateways:

• Cardcom: Terminal numbers, API usernames, operation codes
• Tranzila: Supplier codes, terminal passwords
• PayMe: Seller IDs, API keys
• Meshulam: Page codes, API keys

Israeli Services:

• Israel Post API keys
• Israeli bank API credentials (Poalim, Leumi, Discount, Mizrahi)
• Gov.il API tokens
• Israeli SMS gateways (019, Cellact, InforUMobile) API keys

Using TruffleHog

# Scan git history
trufflehog git file://. --only-verified

# Scan specific branch
trufflehog git file://. --branch main --only-verified

# Scan with JSON output
trufflehog git file://. --json > secrets-report.json

Using Gitleaks

# Scan repository
gitleaks detect --source . --verbose

# Scan with custom config for Israeli services
gitleaks detect --source . --config .gitleaks.toml

# Generate report
gitleaks detect --source . --report-format json --report-path gitleaks-report.json

Recommended .gitleaks.toml additions for Israeli services:

[[rules]]
id = "cardcom-terminal"
description = "Cardcom Terminal Number"
regex = '''(?i)(cardcom|terminal)[\s]*[=:]\s*["']?\d{6,8}["']?'''
tags = ["israeli-payment"]

[[rules]]
id = "tranzila-supplier"
description = "Tranzila Supplier Code"
regex = '''(?i)(tranzila|supplier)[\s]*[=:]\s*["']?[a-zA-Z0-9]{4,20}["']?'''
tags = ["israeli-payment"]

[[rules]]
id = "israeli-sms-api"
description = "Israeli SMS Gateway API Key"
regex = '''(?i)(cellact|inforu|019sms)[\s_-]*(api|key|token)[\s]*[=:]\s*["']?[a-zA-Z0-9]{16,}["']?'''
tags = ["israeli-service"]

Hebrew/RTL-Specific Security

Unicode Bidirectional Text Attacks (Trojan Source)

Bidirectional control characters can make code appear different from what it actually does. This is especially relevant in Hebrew/English mixed codebases.

Dangerous characters to detect:

• U+202A (Left-to-Right Embedding)
• U+202B (Right-to-Left Embedding)
• U+202C (Pop Directional Formatting)
• U+202D (Left-to-Right Override)
• U+202E (Right-to-Left Override)
• U+2066 (Left-to-Right Isolate)
• U+2067 (Right-to-Left Isolate)
• U+2068 (First Strong Isolate)
• U+2069 (Pop Directional Isolate)

Detection script:

import re
import sys

BIDI_CHARS = re.compile(
    '[\u202a\u202b\u202c\u202d\u202e\u2066\u2067\u2068\u2069]'
)

def scan_file(filepath):
    with open(filepath, 'r', encoding='utf-8') as f:
        for line_num, line in enumerate(f, 1):
            matches = BIDI_CHARS.findall(line)
            if matches:
                print(f"WARNING: {filepath}:{line_num} contains "
                      f"{len(matches)} bidirectional control character(s)")

Hebrew Homoglyph Attacks

Some Hebrew characters visually resemble Latin characters, enabling phishing and spoofing:

Mitigation: Normalize and validate all user-facing URLs and identifiers. Reject mixed-script strings in security-sensitive contexts (usernames, URLs, email addresses).

RTL Override in URLs

Attackers can use RTL override characters (U+202E) to disguise malicious URLs:

Example: A URL containing U+202E can make "evil.com/gnp.exe" appear as "evil.com/exe.png"

Mitigation:

• Strip all bidirectional override characters from URLs before processing
• Validate URL structure after Unicode normalization
• Display punycode for internationalized domain names in security-sensitive contexts

Hebrew Input Validation Patterns

// Validate Hebrew-only input (letters, spaces, common punctuation)
const HEBREW_PATTERN = /^[\u0590-\u05FF\s\-'".,:;!?()]+$/;

// Validate mixed Hebrew/English input
const MIXED_PATTERN = /^[\u0590-\u05FFa-zA-Z0-9\s\-'".,:;!?()@#$%&*]+$/;

// Sanitize Hebrew input for XSS prevention
function sanitizeHebrewInput(input) {
  // Remove bidirectional control characters
  let sanitized = input.replace(/[\u202a-\u202e\u2066-\u2069]/g, '');
  // Standard HTML entity encoding
  sanitized = sanitized
    .replace(/&/g, '&')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#x27;');
  return sanitized;
}

// Validate Israeli phone number
const IL_PHONE_PATTERN = /^(\+972|0)(5[0-9]|7[2-9])\d{7}$/;

// Validate Israeli ID number (Teudat Zehut) with check digit
function validateIsraeliId(id) {
  if (!/^\d{9}$/.test(id)) return false;
  let sum = 0;
  for (let i = 0; i < 9; i++) {
    let digit = parseInt(id[i]) * ((i % 2) + 1);
    if (digit > 9) digit -= 9;
    sum += digit;
  }
  return sum % 10 === 0;
}

Secure Coding Patterns

Parameterized Queries for Hebrew Text

// CORRECT: Parameterized query (safe)
const { data, error } = await supabase
  .from('skills')
  .select('*')
  .ilike('name_he', `%${searchTerm}%`);

// INCORRECT: String concatenation (vulnerable to SQL injection)
// const query = `SELECT * FROM skills WHERE name_he LIKE '%${searchTerm}%'`;

// For raw SQL when parameterized queries are needed:
const { data } = await supabase.rpc('search_skills', {
  search_term: searchTerm  // Parameter is safely escaped
});

CSRF Protection for Israeli Payment Forms

// Generate CSRF token for payment form
import { randomBytes } from 'crypto';

function generateCsrfToken(): string {
  return randomBytes(32).toString('hex');
}

// Validate on form submission
function validateCsrfToken(session: string, submitted: string): boolean {
  return session === submitted && session.length === 64;
}

// In payment form (Hebrew UI)
// <input type="hidden" name="_csrf" value={csrfToken} />

Rate Limiting for Israeli SMS Gateways

// Rate limit OTP requests to prevent abuse
// Israeli SMS costs ~0.05-0.15 NIS per message
const OTP_LIMITS = {
  perPhone: { max: 3, windowMs: 15 * 60 * 1000 },    // 3 per 15 min per phone
  perIp: { max: 10, windowMs: 60 * 60 * 1000 },       // 10 per hour per IP
  global: { max: 1000, windowMs: 60 * 60 * 1000 },    // 1000 per hour globally
};

// Implementation with Redis
async function checkOtpRateLimit(phone: string, ip: string): Promise<boolean> {
  const phoneKey = `otp:phone:${phone}`;
  const ipKey = `otp:ip:${ip}`;

  const phoneCount = await redis.incr(phoneKey);
  if (phoneCount === 1) await redis.expire(phoneKey, 900);
  if (phoneCount > OTP_LIMITS.perPhone.max) return false;

  const ipCount = await redis.incr(ipKey);
  if (ipCount === 1) await redis.expire(ipKey, 3600);
  if (ipCount > OTP_LIMITS.perIp.max) return false;

  return true;
}

Compliance Checklist

Israeli Privacy Protection Law (GDPR-Equivalent)

SOC 2 Considerations for Israeli Startups

Israeli startups selling to US enterprises often need SOC 2 compliance:

1. Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy
2. Common control gaps in Israeli startups:
   • Lack of formal change management process
   • Missing access review procedures
   • Incomplete logging and monitoring
   • No formal incident response plan
3. Israeli-specific considerations:
   • IDF service background checks are not a substitute for formal employment screening
   • Israeli holiday calendar affects SLA calculations
   • Hebrew documentation may need English translations for auditors

PCI DSS for Israeli Payment Processing

If your application processes Israeli credit cards (Isracard, Leumi Card, CAL):

1. Level determination: Based on annual transaction volume
2. SAQ selection: Most Israeli web apps qualify for SAQ A or SAQ A-EP
3. Israeli specifics:
   • Shva (the Israeli payment clearing system) has its own security requirements
   • Israeli credit card numbers follow standard Luhn algorithm
   • Israeli recurring payment ("hora'at keva") requires additional consent documentation

Running the Security Audit

Use the included scripts to perform automated checks:

# Run the full security audit checklist
python scripts/security-audit-checklist.py --project-dir /path/to/project

# Scan for Israeli service credentials
bash scripts/secrets-scanner.sh /path/to/project

# Generate a compliance report
python scripts/security-audit-checklist.py --project-dir /path/to/project --format json > report.json

Refer to the references/ directory for detailed guidance on Israeli privacy law and OWASP considerations for Hebrew/RTL applications.

Gotchas

• Israeli Privacy Protection Law was overhauled by Amendment 13 (in force August 14, 2025). A serious security incident must be reported to the Privacy Protection Authority immediately (the law says "immediately", not the GDPR-style fixed 72-hour clock), plus notification to affected individuals where there is high risk. Amendment 13 added a statutory damages head of up to NIS 10,000 / 10,000 ש"ח without proof of harm; do not quote a higher no-proof-of-harm ceiling unconditionally. Agents that quote pre-2025 language miss the new exposure.

• Hebrew UTF-8 characters are 2 bytes each. Input length validation that counts bytes instead of characters will reject valid Hebrew input at half the expected length.

• Israeli ID numbers (Teudat Zehut) use a Luhn-variant check digit algorithm, not standard Luhn. Agents may implement the wrong validation and accept invalid IDs.

• Database registration was narrowed dramatically by Amendment 13 (August 2025): the old "register any database with 10,000+ records" rule was repealed. Registration now applies only to data brokers (databases over 10,000 individuals whose business is selling data) and public bodies, with a separate notification duty for especially-sensitive databases over 100,000 individuals. Agents citing the old general 10,000-record registration threshold are out of date.

• Sending any commercial message (email, SMS, automated call, fax) from an Israeli app is governed by section 30A of the Communications (Telecommunications and Broadcasts) Law, not by the Privacy Protection Law. It requires prior opt-in consent with narrow exceptions, and specific sender-identification and opt-out mechanics inside the message. Section 30A(i)(1) lets a court award damages not dependent on proof of harm of up to NIS 1,000 per advertising message the recipient received in breach. This is the most-litigated Israeli digital-compliance provision and the standard class-action vehicle, so an OTP or marketing flow that passes the PPA checklist can still carry six-figure exposure.

• Bidirectional (BiDi) text attacks are especially dangerous in Hebrew/English mixed codebases. Standard security scanners do not detect RTL override characters (U+202E) that can disguise malicious code.

• A clean run of the bundled scanners is not proof the project is clean. scripts/secrets-scanner.sh scans .env, .env.local and friends but deliberately skips .env.example / .env.sample, and it now aborts with exit code 2 rather than printing "No secrets detected" if grep itself fails. If you see exit 2, the scan did NOT run; never report that as a pass. Pattern matching also cannot see secrets in git history, so pair it with trufflehog git file://. before concluding a repo is clean.

Reference Links