Skip to main content

Web Lab Content Standard

Use the SQL Injection labs in labs/web-application-security/ as the canonical examples for non-CVE web lab pages.

URL​

Use this route pattern:

/labs/web-application-security/<lab-slug>

Example:

/labs/web-application-security/basic-sql-injection

Page Model​

Use one page per lab. Do not group web labs into topic hub pages by default.

This is different from CVE content:

  • CVE labs are usually searched by CVE ID and can support deeper vulnerability detail.
  • Web labs are often scenario or workflow based, such as Discount Code, Invoices, or Ticket Sales.
  • Keep the lab title exactly as it appears in labs.json; do not rewrite it into a vulnerability name.

Frontmatter​

Use this minimum frontmatter shape:

title:
description:
hide_title: true
layout: lab-detail
category_slug: "web-application-security"
category: "Web Application Security"
topic:
access:
points:
premium:
app_slug:
related_trainings:
  - title:
    href:
    image:

Do not add cve or cve_details unless the lab is actually a CVE lab.

Title​

Use the exact lab title from labs.json.

Good:

Discount Code
Basic SQL Injection
Invoices
Ticket Sales

Avoid forcing the title into a vulnerability phrase:

Discount Code Business Logic Vulnerability Lab
Invoices IDOR Vulnerability Lab

The body copy can explain the security topic.

Meta Description​

Write the meta description manually. Keep it concise and search-friendly.

Pattern:

Practice <topic or technique> in a hands-on Hackviser lab. Learn how <scenario> can affect <impact areas>.

Examples:

Practice basic SQL injection in a hands-on Hackviser lab. Learn how unsafe login queries can affect authentication, data access, and input validation.
Practice business logic testing with the Discount Code Hackviser lab. Learn how coupon redemption flaws can affect pricing, abuse prevention, and checkout integrity.

Body Structure​

The lab-detail layout already renders the outer Overview heading. Do not add ### Overview inside the Markdown body.

Use this content order:

Short intro paragraph.

Overview body paragraph, without an `### Overview` heading.

### Security Impact

Explain what the issue can cause in real applications.

### Vulnerability Scope

Explain where this pattern appears: forms, workflows, endpoints, parameters, business flows, etc.

### Lab Focus

Explain what the learner practices conceptually.

### Related Labs

Add 2-4 internal links to labs in the same topic.

Add related_trainings when there is a directly relevant training page.

Keep it curated:

  • Prefer 1-2 trainings.
  • Use real training routes only.
  • Include the training image URL from trainings/index.mdx.
  • Do not add broad trainings just to fill space.

Example:

related_trainings:
  - title: "SQL Injection"
    href: "/trainings/sql-injection"
    image: "https://storage.hackviser.com/file/hackviser-prod/trainings/f07e1708768b4f59a2339ee97028fa0f.webp"
  - title: "Using SQLMap"
    href: "/trainings/using-sqlmap"
    image: "https://storage.hackviser.com/file/hackviser-prod/trainings/659ac244a8704f6abad3a626d2093838.webp"

Public Content Rules​

Do not include:

  • Lab answers
  • Secret file names as objectives
  • Credentials
  • Step-by-step exploitation instructions
  • Payloads
  • Tool commands
  • Overly specific parameters if they reveal the lab solution

It is fine to mention the vulnerable workflow at a high level, such as login flow, search function, stock control, checkout, invoice access, or password reset.

SEO Rules​

  • Keep each page useful on its own.
  • Avoid repeating the same generic topic explanation across every lab.
  • Use the lab-specific scenario to make each page unique.
  • Use internal links through Related Labs and Related Trainings.
  • Keep headings descriptive and consistent.
  • Keep content short enough for web labs; do not force CVE-style depth where the lab does not need it.