Application Security Testing Practices and Risk Assessment at JD Daojia

Table of Contents

Background

Security Risk Analysis

Security Testing Practices

Security Testing Effect Evaluation

Conclusion

Background

JD Daojia, the leading local instant‑retail platform of the Dada Group, delivers a wide range of goods (supermarket items, fresh produce, medicines, etc.) to consumers within about one hour. As the business expands and regulatory scrutiny on enterprise security intensifies, vulnerabilities and data leaks could cause tens of millions of yuan in losses and heavy penalties, making pre‑release security assurance essential.

Security Risk Analysis

To eliminate security flaws before launch, JD Daojia first needed to identify the primary sources of vulnerabilities and how to discover them early. While the underlying infrastructure follows JD’s robust host‑ and network‑security standards, application‑level security—especially components tightly coupled with business logic—remains the weakest link. Historical penetration tests and red‑blue exercises show that most discovered issues reside in the application layer, establishing application security testing as the primary goal.

Security Testing Practices

Application security spans the entire lifecycle from requirement design to online operation. Well‑known frameworks such as SDL and DevSecOps define four stages where security testing intervenes: security assessment, open‑source component scanning, vulnerability scanning, and manual security testing.

Security Assessment Stage

During requirement design and review, the security team provides recommendations to prevent vulnerabilities at the source. Because security resources are limited, JD Daojia adopts two assessment strategies:

Strategy 1: For newly introduced systems or those handling privacy‑sensitive data, a thorough assessment is performed, often using the STRIDE threat‑modeling methodology.

Strategy 2: For routine iterative systems, security testing is applied directly during the testing phase.

Proactive identification of systems requiring assessment relies on a clear understanding of core data assets and change‑impact risk, supplemented by security‑awareness training for product managers.

Data‑flow diagram of JD Daojia customer‑service system

Threat‑Mitigation Table (Translated)

Threat

Definition

JD Daojia Customer‑Service System Element

Mitigation Measures

Impersonation (S)

Fake person or entity

Client app

Server‑side encrypted PIN for login accounts

Tampering (T)

Modify data

Data‑flow request

HTTPS to prevent man‑in‑the‑middle attacks

Repudiation (R)

Denial of performed actions

Client app, customer‑service system

Log monitoring, chat‑record backup

Information Disclosure (I)

Leak or theft of information

Customer‑service system, stored customer data

Personal data masking, encrypted storage

Denial of Service (D)

Service becomes unavailable

Data‑flow request

High‑concurrency request validation, queue throttling

Elevation of Privilege (E)

Unauthorized privilege acquisition

Customer‑service system

Penetration testing for privilege escalation, least‑privilege policy

Threat mitigation comparison table for JD Daojia customer‑service system

Open‑Source Component Scanning

This stage ensures third‑party dependencies are free of known vulnerabilities before release. By integrating scanning into JD’s unified release platform, the process becomes an automatic gate, eliminating the need for developers to rely solely on IDE plugins.

Vulnerability Scanning Stage

SAST (Static Application Security Testing) – Conducted during coding using Sonar to automatically generate reports that are routed to owners for remediation.

DAST (Dynamic Application Security Testing) – Tools such as X‑Ray, Burp, Acunetix (Awvs), and Goby are used for daily scanning. While black‑box scans find fewer issues, newly discovered vulnerabilities are actively probed.

IAST (Interactive Application Security Testing) – Utilizes both proxy‑mode and instrumentation‑mode scanning. JD Daojia currently prefers proxy mode to avoid intrusive instrumentation. Passive proxy scanning is performed in test environments to prevent dirty data from affecting production.

Future work includes building a traffic‑center to automatically feed logs from Logbook and testing platforms into the scanner, achieving fully automated interactive scanning.

Manual Security Testing

Automated SAST/DAST/IAST cover many generic issues, but business‑logic flaws require manual testing. JD Daojia adopts three coverage strategies:

App‑centric testing for each release, focusing on app‑specific vulnerabilities, backend injection, business‑logic errors, and privacy compliance.

Periodic web‑application testing for merchant and operations systems, which have fewer changes but handle core data.

Empowering business testers with basic security‑check skills, enabling early detection of over‑privilege, sensitive‑data transmission, and logic bugs; historically ~20% of defects are found by these testers.

Security Testing Effect Evaluation

To verify coverage, JD Daojia tracks metrics such as the number of vulnerabilities discovered in crowdsourced testing, red‑blue exercises, and internal scans. Recent findings include:

A significant reduction in the total number of vulnerabilities reaching production.

No high‑severity leaks in the consumer app or merchant portal over the past year.

Remaining issues are mostly due to missing security policies rather than isolated code bugs.

Conclusion

Implementing a full DevSecOps pipeline—covering assessment, component scanning, SAST/DAST/IAST, and manual testing—has markedly decreased live security incidents. Ongoing work focuses on fully automating IAST (including instrumentation) and further integrating traffic‑center data. Because zero‑vulnerability releases are unrealistic, continuous security operations, employee awareness programs, and regular red‑blue exercises remain essential for robust protection.