Sign up to save your podcastsEmail addressPasswordRegisterOrContinue with GoogleAlready have an account? Log in here.
Welcome to CyberCode Academy — your audio classroom for Programming and Cybersecurity.🎧 Each course is divided into a series of short, focused episodes that take you from beginner to ad... more
FAQs about CyberCode Academy:How many episodes does CyberCode Academy have?The podcast currently has 213 episodes available.
November 12, 2025Course 2 - API Security Offence and Defense | Episode 1: API Fundamentals: Standards, Versioning, and Investigative TechniquesIn this lesson, you’ll learn about:APIs — Definition & Evolution:API (Application Programming Interface): A mechanism originally designed to allow software to access operating system libraries; now primarily used for data exchange between servers, web apps, mobile apps, and frontend frameworks like React or Vue.Evolution of API standards:XML-RPC: Early XML-based method, complex and insecure.SOAP (Simple Object Access Protocol): Standardized XML-based protocol, widely adopted but rigid.REST (Representational State Transfer): Modern standard, relies on HTTP methods (GET, POST, PUT, DELETE) and commonly uses JSON or XML.REST API Structure & Versioning:HTTP Methods & CRUD mapping:GET / HEAD: ReadPOST: CreatePUT / PATCH: UpdateDELETE: DeleteRequest Components:Headers: Authentication (Authorization: Bearer ), Accept for content type negotiation.Response Headers: WWW-Authenticate, Content-Type, Set-Cookie, CORS headers.Status Codes: e.g., 200 OK, 201 Created, 404 Not Found, 405 Method Not Allowed, 500 Internal Server Error.Versioning: Ensures older clients continue functioning; can be implemented via URL path (/v1), Accept headers, or custom headers.API Fingerprinting & Discovery:Key info to gather:API endpoints and domains (e.g., api.example.com)Versioning methodProgramming language and backend storage (SQL, NoSQL, caches like Redis)Authentication mechanismTechniques: Public documentation review, subdomain enumeration, intercepting client traffic via proxies, and deducing backend details from headers or job postings.Debugging & Automated Testing:Proxy Tools: Burp Suite for intercepting, modifying, and forwarding API requests.API Testing Tools: Postman to construct requests, specify methods, headers, and bodies (JSON payloads).Fuzzing: Automated testing by sending malformed/unexpected inputs to detect exceptions or abnormal HTTP responses (e.g., 500 errors).Authentication vs. Authorization:Authentication: Verifying identity (ID/password, tokens, cookies, API keys, JWT, OAuth).Authorization: Determining allowed actions for an authenticated client (e.g., admin vs. user privileges).Core takeaway: Understanding API architecture, endpoints, authentication/authorization mechanisms, and using proxy/debugging tools is essential for secure interaction, discovery, and testing of APIs.You can listen and download our episodes for free on more than 10 different platforms:https://linktr.ee/cybercode_academy...more11minPlay
November 12, 2025Course 1 - BurpSuite Bug Bounty Web Hacking from Scratch | Episode 12: Cookies, Sessions, and Session Management Manipulation VulnerabilityIn this lesson, you’ll learn about:HTTP is stateless: every request is independent, so web apps must implement state mechanisms to track users.Cookies — client-side state: small text files (≈4 KB) stored in the browser holding prefs, auth data, and often session IDs; key attributes: Domain, Path, Expires, Secure (HTTPS-only), and HttpOnly (not accessible to JavaScript).Sessions & Session IDs — server-side state: session data lives on the server and is referenced by a unique, high-entropy Session ID (long, random alphanumeric string) sent to the client; sessions are generally more secure because sensitive data is not exposed to the client.Security properties: ensure Session IDs are random, long, rotated after privilege changes (e.g., post-login), and invalidated on logout/timeout; prefer server-side storage for sensitive state.Cookie vs. Session tradeoffs: cookies provide persistence and client-side convenience but expose data to the client; sessions keep data server-side but require secure Session ID management.Common session-management vulnerabilities: predictable or reused session IDs, session fixation (reusing same ID before/after login), session IDs in URLs, lack of invalidation, and insecure cookie flags leading to theft via XSS.Practical exploitation demo (session manipulation): editing cookies can change user identity if server trusts client-side identifiers (e.g., modifying UID cookie allowed switching accounts), demonstrating weak server-side authorization checks.Mitigations & best practices: never trust client-side identifiers for authorization, use secure cookie flags (Secure, HttpOnly, SameSite), rotate session IDs on privilege changes, implement strict session timeouts and invalidation, and store sensitive state server-side.Core takeaway: robust session management requires secure Session ID generation, careful cookie handling, and server-side authorization — otherwise attackers can hijack or impersonate users via simple cookie/session manipulation.You can listen and download our episodes for free on more than 10 different platforms:https://linktr.ee/cybercode_academy...more14minPlay
November 12, 2025Course 1 - BurpSuite Bug Bounty Web Hacking from Scratch | Episode 11: Injection and Directory Path Traversal Attacks.In this lesson, you’ll learn about:Critical Web Security Vulnerabilities — Overview: Focus on Injection Attacks and Directory Path Traversal Attacks, two high-risk categories in web applications.Injection Attacks — definition & mechanism:Occur when untrusted input is sent to an interpreter (SQL, OS commands, HTML, CSS, or JavaScript), altering program execution.Can lead to data theft, data loss, denial of service, or full system compromise.Types include:Client-side: Cross-Site Scripting (XSS), HTML injection, CSS injection.Server-side: SQL injection, command injection, CRLF injection.Requires input/output interaction with the web application or database.Directory Path Traversal (Path Traversal) — definition & mechanism:HTTP attack allowing attackers to bypass web server restrictions and access files outside the designated root directory.Exploits file path parameters by inserting traversal sequences like ../ to move up directories.Targets include sensitive files:Windows: web.configLinux: /etc/passwdConsequences:Unauthorized access to critical files, application configuration, and sensitive system data.Potential for executing arbitrary commands depending on server privileges.Detection & Demonstration:Attackers test parameters by adding ../ sequences and observing responses.Successful access indicates improper input validation and insufficient access controls.Mitigation & Best Practices:Keep web server software updated with latest patches.Validate and sanitize all user inputs, filtering out meta-characters (../, %2e%2e/, etc.).Restrict server environment to only necessary data and remove unused files.Implement proper Access Control Lists (ACLs) and enforce directory confinement.Key takeaway:Protecting against injection and path traversal attacks requires both input validation and secure configuration of server directories and application logic.You can listen and download our episodes for free on more than 10 different platforms:https://linktr.ee/cybercode_academy...more13minPlay
November 12, 2025Course 1 - BurpSuite Bug Bounty Web Hacking from Scratch | Episode 10: XSS: Overview, Security Level Testing, and Real-World AttacksIn this lesson, you’ll learn about:Definition of Cross-Site Scripting (XSS):A client-side web vulnerability where an application executes user-supplied JavaScript instead of treating it as text. It typically occurs in user input areas such as search fields, comment boxes, or feedback forms.Main Types of XSS:Reflected XSS (Non-persistent):The malicious input is not stored in the database.It only affects users who execute the injected script (e.g., by clicking a crafted link).Commonly found in search or URL parameters.Stored XSS (Persistent):The injected payload is saved in the application database (e.g., in comments).The script runs automatically for every visitor who loads the infected page.This type has a higher impact and broader reach.DOM-based XSS:The vulnerability exists in the Document Object Model (DOM) layer.The HTML response may appear unchanged, but JavaScript execution happens client-side.Potential Consequences:Theft of cookies and session tokens.Hijacking user accounts or sessions.Launching Cross-Site Request Forgery (CSRF) attacks.Delivering malicious redirects or keyloggers.Practical Demonstrations:Reflected XSS (OWASP Mutillidae Example):Using Burp Suite to intercept and inject a simple payload:If the response returns the payload unmodified, the application is vulnerable.DVWA Demonstrations Across Security Levels:Low Level: The script runs immediately without filters.Medium Level: Filtering is attempted (e.g., removing the word “script”). Bypassed using mixed-case payloads like:High Level: Stronger filtering, but DOM-based XSS succeeds using:Real-World Exploitation Example:Attackers send phishing emails containing legitimate-looking links that include malicious JavaScript in the query string.When clicked, the script executes on the target site, allowing theft of credentials or session data.This is often referred to as first-order XSS, primarily exploiting GET requests.Prevention Techniques:Validate and sanitize all user input (both client and server-side).Implement output encoding for HTML, JavaScript, and URL contexts.Use modern Content Security Policy (CSP) headers.Avoid using innerHTML for dynamic content updates.Educate users to verify links before clicking, especially in unsolicited emails.You can listen and download our episodes for free on more than 10 different platforms:https://linktr.ee/cybercode_academy...more18minPlay
November 12, 2025Course 1 - BurpSuite Bug Bounty Web Hacking from Scratch | Episode 9: Understanding and Finding SQL Injection VulnerabilitiesIn this lesson, you’ll learn about:SQL Injection (SQLi) — definition & importance: what SQL is (Structured Query Language) and why data-driven apps are high-value targets for injection attacks.Core mechanism: how attackers inject malicious input into dynamic SQL statements (queries built from runtime parameters) to alter logic — e.g., commenting out parts of a query or appending always-true conditions.Types of SQLi: error-based, blind (boolean), time-based, and union-based injections — each exploits the DB engine differently and requires different discovery/exploitation techniques.Potential impact: full database disclosure (dumping data), modifying/inserting/deleting records, or otherwise corrupting application data and functionality — impact depends on DB engine and privileges.Discovery approach — fuzzing & logic-first mindset: understand the application flow and likely backend queries, then feed “weird input” to break or alter the SQL (fuzzing is the primary discovery method).Basic test techniques:Quotes: submit single (') or double (") quotes to provoke syntax errors — a common initial test for SQLi.Backslashes / escapes: use \ (or DB-specific escape chars) to break query parsing in some engines (e.g., MySQL).Choose the technique that matches the app’s input handling (single-quote, double-quote, or backslash may work differently).Automation: use tools (or Burp Intruder) to automate payload lists once you know which delimiter/escape style affects the target. Monitor responses for errors, content changes, or timing differences.Detection signals: SQL errors in responses, changes in content length/body, boolean differences, or time delays (for time-based tests) indicate possible vulnerability.Next steps after detection: escalate from proof-of-concept errors to controlled data extraction techniques (union queries, blind extraction techniques, or time-based exfiltration) while keeping tests minimal and authorized.Analogy (teaching aid): like a locksmith trying different picks (quotes, backslashes) in a lock (input field) to find the one that opens the mechanism (causes the backend SQL to fail or execute attacker-controlled logic).Ethics & safety note: always test within authorized scope, avoid destructive payloads, and document findings/steps for reproducible PoCs.You can listen and download our episodes for free on more than 10 different platforms:https://linktr.ee/cybercode_academy...more12minPlay
November 12, 2025Course 1 - BurpSuite Bug Bounty Web Hacking from Scratch | Episode 8: Exploiting Hidden Administrative Pages and Directory ListingIn this lesson, you’ll learn about:Security Misconfiguration — overview: a broad class of vulnerabilities caused by insecure defaults, incorrect application logic, or poorly documented configuration choices.Why it matters: misconfigurations often expose sensitive functionality or data and are frequently exploitable with low effort, making them high-impact risks.Secret administrative pages (hidden-by-obscurity):Developers sometimes “hide” admin pages by using obscure filenames (e.g., admin.php) instead of enforcing access controls.Attack technique: brute force or dictionary-based guessing of common admin filenames/paths (using tools like Burp Intruder).Demonstration outcome: discovered hidden admin page and exposed configuration UI—shows that obscurity ≠ security.Directory listing vulnerabilities:Definition: web server exposes a directory’s file list when no index file exists.Impact: attackers can enumerate files (configs, backups, scripts) and retrieve sensitive data without complex exploits.Demonstration outcome: discovered exposed files (e.g., config.inc) revealing DB credentials and other secrets.Testing approaches demonstrated: use automated requests (Intruder), spidering, and targeted parameter fuzzing to discover hidden pages and directory listings.Detection signals: presence of index-missing directory pages, unexpected file names in listings, or responses revealing configuration details.Mitigations & best practices:Disable directory listing on web servers and ensure default index files are in place.Enforce proper authentication and authorization on admin/management pages (don’t rely on obscurity).Remove or secure development/debug pages and sensitive files before deployment.Implement least-privilege file permissions and avoid storing secrets in web-root files.Regularly scan for exposed endpoints (automated discovery + manual review) and include config checks in CI/CD pipelines.Practical recommendation: treat every endpoint as potentially discoverable—harden server defaults, perform regular configuration audits, and document config changes to prevent accidental exposures.You can listen and download our episodes for free on more than 10 different platforms:https://linktr.ee/cybercode_academy...more12minPlay
November 12, 2025Course 1 - BurpSuite Bug Bounty Web Hacking from Scratch | Episode 7: Insecure Direct Object Reference (IDOR): Understanding, TestingIn this lesson, you’ll learn about:IDOR (Insecure Direct Object Reference) — definition: when user-supplied references (IDs) let attackers access or modify objects they’re not authorized to (files, records, accounts).Core mechanism: the app trusts the client-supplied identifier instead of enforcing authorization checks on the server side.Simple IDOR testing (numeric IDs): try adjacent or sequential IDs (e.g., /user=123 → /user=124) and watch for different responses.Automation of basic tests: use tools like Burp Intruder with a numeric payload (start/stop/step) and monitor response lengths/status for differences.Detection signals: changing content length, differing response bodies, or absence/presence of access-denied messages indicate possible IDOR.Advanced IDOR — obscured IDs (UUIDs): UUIDs are hard to guess; testing requires finding where the UUID leaks (page source, API responses, invitation flows, team endpoints).Techniques to find UUID leaks: inspect page source, JSON responses, invitation links, or any client-side data that may expose identifiers.Impact & reporting: even non-guessable IDs are valid findings if sensitive data can be accessed; explain impact clearly to evaluators.Practical demo — file access IDOR: intercept a request (e.g., source_viewer.php?file=user_file.php), modify the file parameter to an unauthorized target (e.g., index.php) and observe source disclosure.Mitigations: enforce server-side authorization checks for every object access, use indirect references or per-user mapping, avoid predictable IDs in URLs, and implement least privilege for object access.Analogy (teaching aid): like a hotel key coded with a room number — if you can change the number on your key and open other rooms, the system is IDOR-vulnerable.You can listen and download our episodes for free on more than 10 different platforms:https://linktr.ee/cybercode_academy...more13minPlay
November 12, 2025Course 1 - BurpSuite Bug Bounty Web Hacking from Scratch | Episode 6: Broken Authentication and Session Management: Exploits and DefensesIn this lesson, you’ll learn about:Broken Authentication and Session Management (BASM):A critical OWASP Top 10 vulnerability that arises from poor handling of user authentication and session controls.Common causes include developer negligence and insecure practices that allow attackers to hijack or reuse valid sessions.Key causes and developer mistakes:Exposing session IDs in the URL.Failing to implement proper session timeouts.Reusing the same session ID before and after login.Storing or transmitting session cookies insecurely, making them vulnerable to theft (e.g., via XSS).Common exploitation methods:Brute Force Attacks:Attackers use automated tools (like Burp Suite Intruder in cluster bomb mode) to guess valid username-password pairs.Exploits weak password policies or lack of rate-limiting.SQL Injection Login Bypass:Attackers inject malicious SQL payloads (e.g., 1=1, ' OR '1'='1) into login fields.The server interprets the input as a valid condition, granting unauthorized access without valid credentials.Prevention and mitigation strategies:Implement Multi-Factor Authentication (MFA): Adds an extra verification layer against stolen or brute-forced credentials.Enforce strong password policies: Disallow weak or default credentials; check against known password breach lists.Prevent account enumeration: Use identical messages for login, registration, and recovery outcomes.Limit failed login attempts: Apply lockouts, rate limits, and alert administrators of repeated failures.Use secure session management:Generate new random session IDs after login (high entropy).Avoid placing session IDs in URLs.Invalidate sessions on logout or inactivity.Store session data securely on the server side.Core takeaway:Understanding BASM helps identify how insecure session handling and weak authentication mechanisms can compromise entire systems. Applying layered defenses ensures both authentication robustness and session integrity.You can listen and download our episodes for free on more than 10 different platforms:https://linktr.ee/cybercode_academy...more13minPlay
November 12, 2025Course 1 - BurpSuite Bug Bounty Web Hacking from Scratch | Episode 5: Utilizing Burp Suite Decoder, Comparer, Sequencer, and Engagement ToolIn this lesson, you’ll learn about:Burp Decoder — purpose & features: decode/encode request and response content (URL, HTML, Base64, ASCIIhex, etc.); smart-decode that detects likely encodings automatically; useful for deobfuscating payloads and analyzing encoded data.Burp Comparer — purpose & uses: visually diff two pieces of content (requests/responses) to highlight added, removed, or changed text; great for spotting subtle response differences during username enumeration, analyzing Intruder outputs, or comparing blind-SQLi responses.Burp Sequencer — purpose & methodology: collect samples of tokens (session IDs, CSRF nonces) via live capture or manual input; run statistical/randomness tests (including FIPS-like tests) to evaluate entropy and predictability of serial values.Supplemental engagement tools — overview & workflows:Search: find strings or regexes across requests/responses to locate indicators or sensitive data.Analyze target: map dynamic vs. static content and enumerate parameters to organize testing.Discover content: brute-force files/directories using wordlists and extensions to reveal hidden endpoints.Find commands/scripts/references: locate inline commands, client/server scripts, comments, and external references that may leak sensitive info.Schedule task / Simulate manual testing: administrative helpers (note: “Simulate manual testing” is largely cosmetic according to the source).Practical guidance: combine these utilities with Proxy/Repeater/Intruder workflows—use Decoder to prepare payloads, Comparer to validate behavioral differences, Sequencer to verify token strength, and Discover/Analyze tools to expand your attack surface.Security & process note: gather samples and perform destructive tests only within authorized scope; document findings and test methods for reproducible PoCs.You can listen and download our episodes for free on more than 10 different platforms:https://linktr.ee/cybercode_academy...more14minPlay
November 12, 2025Course 1 - BurpSuite Bug Bounty Web Hacking from Scratch | Episode 4: Burp Suite Proxy: Configuration, Request Interception, and RepeaterIn this lesson, you’ll learn about:Burp Proxy tab — purpose & subtabs: Intercept (toggle request interception), HTTP History (record of proxied requests), and Options (listen address/port configuration).How the proxy works: Burp listens for browser traffic on a configured IP and port (default 127.0.0.1:8080); the browser must be configured for manual proxying to point to the same host/port.Intercept workflow: with Intercept on you can view request details (headers, cookies, params, user-agent), then Forward the request to the server or Drop it to stop it.Configuring the listening interface: use Proxy → Options to change the bind address/port or add additional listener entries (useful for VM / remote testing).Recommended browser: use a separate testing browser (Mozilla Firefox recommended) to avoid contaminating your daily browser profile.Handling HTTPS traffic: Burp generates per-host SSL certs signed by its own CA — install Burp’s CA certificate into the browser (visit http://burp while proxied to download it), then mark it trusted (“Trust this CA to identify websites”) and restart the browser. This allows Burp to intercept HTTPS without browser warnings.Security caution: only install Burp’s CA in a dedicated testing profile or VM; remove it from normal/production profiles to avoid trusting a local CA inadvertently.Repeater tool — purpose: used for manual, iterative testing of a single request—edit, resend, and observe responses without redoing actions in the browser.Sending requests to Repeater: from Proxy Intercept or HTTP History use “Send to Repeater” (or Ctrl+R) to move a request into Repeater.Repeater workflow: edit the HTTP message in the text editor, press Go to send, and inspect response metadata (status, length, timing) and body to assess effects.Use cases for Repeater: manual vulnerability verification and PoC creation (e.g., testing XSS payloads, parameter tampering, SQLi strings) by injecting payloads and observing returned HTML/headers.Round-trip to browser for client validation: after modifying a request in Repeater you can generate/replay a URL in the browser to validate client-side behavior (useful for DOM/XSS checks).Practical recommendations: verify proxy and CA settings with a simple request first, keep scope/legal authorization documented, and use an isolated VM/profile for all interception tasks.You can listen and download our episodes for free on more than 10 different platforms:https://linktr.ee/cybercode_academy...more16minPlay
FAQs about CyberCode Academy:How many episodes does CyberCode Academy have?The podcast currently has 213 episodes available.