Cyber Security

1. Definition

Frontend = everything the user sees and uses, communicating with the backend (server & database) behind the scenes.

It may be:

1. Desktop Frontend
   The graphical user interface (GUI) of applications installed on desktop operating systems (Windows, macOS, Linux). Built with frameworks like Electron, WPF, JavaFX, .NET MAUI.
   
   

2. Web Frontend
   The client-side interface of web applications accessed via browsers. Uses HTML, CSS, JavaScript (and frameworks like React, Angular, Vue). Runs cross-platform without installation.
   
   

3. Mobile Frontend
   The user-facing part of apps on smartphones/tablets (iOS, Android). Built natively (Swift, Kotlin) or cross-platform (Flutter, React Native). Optimized for touch, small screens, and mobility.
   
   

4. Smart TV Frontend
   The interface of applications on Smart TVs (Samsung Tizen, LG webOS, Android TV, Roku). Focuses on large-screen UX, remote-control navigation, and streaming services.
   
   

5. Kiosk Machine Frontend
   Touchscreen interfaces for public/retail self-service machines (ATMs, ticketing, ordering systems). Designed for simplicity, accessibility, and durability, often running in locked-down environments.

2. Potential Attacks

• Cross-Site Scripting (XSS)

  1. Escape user input; use Content Security Policy (CSP)

  2. element.textContent = userInput;

• Cross-Site Request Forgery (CSRF)

  1. Use SameSite cookies, CSRF tokens

  2. Set-Cookie: token=abc; SameSite=Strict

• Clickjacking

  1. Use X-Frame-Options or CSP frame-ancestors

  2. X-Frame-Options: DENY

  3. [ X-Frame-Options - X-Content-Type-Options - X-XSS-Protection - Content-Security-Policy ]

• Insecure Data Storage

  1. Avoid localStorage/sessionStorage for sensitive data

  2. Use HTTP-only cookies

  3. Sensitive Data Exposure

  4. Use HTTPS, encrypt data

  5. fetch('https://example.com')

  6. DOM-based XSS

  7. Sanitize dynamic DOM manipulation

  8. Use DOMPurify

  9. Disable autocomplete on sensitive fields 

• Insecure Redirects

  1. Validate redirect URLs

  2. Check with the whitelist before redirecting

• Information Leakage via Comments

  1. Remove comments before production

  2. <!-- remove before release -->

• Source Code Exposure

  1. Use obfuscation and minification

  2. UglifyJS or Terser

• Hardcoded Secrets

  1. Store in secure backend, not frontend

  2. Use environment variables server-side

• DDoS

1. Validate file uploads: type, size, content

2. Apply DomPurify on the HTML content, as it protect from user code injection

3. Use innerText not innerHTML when possible 

3. Security Approach

• Authentication hardening:

  • • Authentication levels:

      • What you know(User name and password): Simple

      • What you have(Access card): Med

      • What you are(Face detection/finger print (Called biometric): Hard

    • MFA: using multiple options to make sure of who is performing the action

    • CAPTCHA: using it to make sure of what performing the action, human or machine.

• Obfuscation

  • • Obfuscation is the process of deliberately making code, data, or communication harder to understand, while keeping functionality intact. 

    • Goal: Prevent reverse engineering, intellectual property theft, and exploitation by attackers. 

    • Techniques:

      • • Code renaming & control-flow flattening

• String/data encryption

• Dead-code insertion

• Binary packing

• Use Cases: Protect source code (Java, JavaScript, .NET), secure APIs, hide algorithms in proprietary software, and harden malware (dual-use).

• CSP: 

  • • Definition: CSP is a web security standard (W3C) that controls which resources (scripts, styles, images, etc.) a browser is allowed to load and execute.

    • Goal: Mitigate Cross-Site Scripting (XSS), data injection, and clickjacking attacks by restricting untrusted content sources.

    • Use Cases:

• Allow scripts only from trusted CDNs

• Block inline/eval JavaScript

• Prevent loading of mixed (HTTP) content

• Control if site can be embedded in iframes

• • • Sample for strong CSP:

      • Content-Security-Policy:

      • default-src 'self';

      • script-src 'self' cdn.example.com;

      • style-src 'self' fonts.googleapis.com;

      • font-src fonts.gstatic.com;

      • img-src 'self' data:;

      • object-src 'none';

• CORS

  • • Definition: CORS is a browser security mechanism that controls how web applications request resources from a different domain (cross-origin).

    • Goal: Protect users from malicious websites trying to access sensitive data from another origin (e.g., banking sessions).

    • Mechanism:

      • • Server responds with headers like Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers.

        • Browsers enforce rules; preflight requests (OPTIONS) check permissions before sensitive calls.

        • Use Cases:

• Allow specific frontend domains to call backend APIs.

• Secure public APIs with controlled exposure.

• Restrict admin APIs to same-origin only.

• Caching

  • use HTTPOnly to prevent accessing by JS

  • Encrypt cached data

  • Do not cache sensitive data on the frontend

• Store secrets on BE, not FE

4. CAPTCHA In Depth:  

• • • CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a security measure used to distinguish between human and automated users (bots) on the internet.

    • How does it work?

      • The server generates a test and sends it with the web page.

      • The client (you) solves it and submits the solution.

      • The server verifies the answer and decides:

      • ✅ Pass → Continue (human).

      • ❌ Fail → Block/suspicious (likely bot)

  • CAPTCHA Governance

5. When/Where to insert CAPTCHA?

Here are additional CAPTCHA insertion points to enhance protection against bots:

1. Bot Mitigation – To prevent automated abuse (credential stuffing, spam, fake registrations, scraping).

2. Public-Facing Forms – Login, registration, password reset, comment sections.

3. Rate-Limited Services – Before throttling kicks in, add CAPTCHA to discourage bots.

4. Anonymous User Access – When the user is not yet authenticated (pre-login).

5. Password or Email Change – prevent unauthorized credential updates.

6. Account Deletion or Data Export (GDPR) – block malicious automated actions.

7. Checkout Process (Submitting) or Adding New Payment Methods – prevent fraud attempts.

8. Sensitive Actions in Dashboard – e.g., changing user roles or permissions.

9. Bulk Content Publishing – avoid mass spam uploads or auto-generated content.

10. High-Frequency Search Requests – throttle scraping or brute-force lookups.

11. Resending Activation Codes or OTP – stop abuse of verification endpoints.

12. Username Recovery Flows – prevent brute-force discovery of usernames.

13. Public API Access Without Authentication – add CAPTCHA before processing.

14. Inserting External Links in Comments/Chats – reduce link spam.

6. Frontend Caching Approaches:  

Section 1: Persistence

• localStorage: Persists after browser close / device restart

• sessionStorage: Cleared when tab or browser closes
  
  

Section 2: Attack Surface

• localStorage: 🚨 Higher XSS risk (data stays longer)

• sessionStorage: ⚠️ Lower XSS risk, but still vulnerable
  
  

Section 3: Scope

• localStorage: 🌐 Shared across all tabs of same domain

• sessionStorage: 📄 Tab-specific only
  
  

Section 4: Authentication Use

• localStorage: ❌ Unsafe for JWT or tokens

• sessionStorage: ⚠️ Safer but still not recommended
  
  

Section 5: Best Practices

• Don’t store sensitive data (tokens, passwords)

• Use for temporary or non-sensitive UI state

• Apply CSP + input sanitization to reduce XSS

• Prefer HttpOnly Secure Cookies for authentication

7. OTP: What and When?  

Definition: OTP (One-Time Password) is a temporary, single-use code used to authenticate a user for a specific action or session.

Purpose: Adds an extra security layer beyond username/password (part of MFA).

Validity: Typically valid for a short time (e.g., 30–300 seconds) or a single transaction.

Delivery Methods: SMS, email, authenticator apps (like Google Authenticator), hardware tokens.

Use Cases: Login verification, financial transactions, password resets, sensitive data access.

Security Advantage: Reduces risk of credential theft because the code expires quickly and cannot be reused.

 When to use it?

1. Public-Facing Forms: Login, registration, password reset, and comment sections.

2. Payment: Protects financial transactions (PCI DSS, PSD2 compliance). Mitigates fraud and unauthorized payments.

3. Journey execution: Create a transaction on behalf of another

4. Dynamic Definition: Customer to define sensitivity for the journey step, which should have MFA, and MFA method (OTP/email/WhatsApp)

5. Document Downloads: Secure customer documents

6. Access Sensitive Data: By F2F employees: Customer profiles

7. Access Sensitive Data: By Customer: Customer profiles

8. Assets Transfer: change ownership between customers

7. Tools: ESlint  

ESLint doesn’t actually stand for anything (it’s not an acronym).

The name comes from:

• “Lint” → a term from the Unix world (the original lint tool scanned C code for errors). It means static analysis tool that finds problems in code.
  
  

• “ES” → short for ECMAScript (the standard behind JavaScript).
  
  

👉 So ESLint = Linter for ECMAScript (JavaScript).

Best ESLint Plugins for Security in React

1. eslint-plugin-security

   • Detects common security issues like eval(), RegEx DoS, unsafe object property access, etc.

   • Not React-specific, but protects JS code you write in React apps.
     
     

2. eslint-plugin-no-secrets

   • Prevents hardcoding API keys, secrets, and credentials in React code.
     
     

3. eslint-plugin-jsx-no-script-url (sometimes included in React rules)

   • Blocks dangerous patterns like href="javascript:void(0)".
     
     

4. eslint-plugin-sonarjs

   • Flags suspicious or vulnerable coding patterns (e.g., complexity, hidden bugs).
     
     

5. eslint-plugin-unicorn

   • Has some security-related rules (like avoiding deprecated/dangerous APIs).