Shopee security headers do not operate in isolation. To understand why a request succeeds, triggers verification or is rejected, separate at least four layers: the HTTP message, session state, the TLS connection and the application/device context. Matching a URL and a handful of headers does not establish that two requests are equivalent.
This research note moves from fields such as af-ac-enc-dat, af-ac-enc-sz-token and x-sap-access-* to TLS fingerprints, device integrity and bot-detection models. Its purpose is to build a testable method of analysis, rather than attribute every failure to a "missing token" or "emulator detection."
Research scope: selected Shopee Singapore Android test sessions from 15–16 October 2026, reviewed and edited on 21 October 2026. Findings apply to the samples observed, not to Shopee's internal specification. Data examples are illustrative, with substituted values; they are not usable credentials.
1. What are Shopee security headers?
HTTP headers describe aspects of a request or response. Some belong to established HTTP standards; others are defined by an application. "Security headers" is often used loosely for fields associated with authentication, session state, integrity checks or contextual information.
Distinguish a documented purpose from an inferred purpose. For standard headers, consult the relevant specification. For Shopee-specific names, a prefix such as enc, token or access, or a value resembling a timestamp, provides a starting hypothesis rather than an implementation description.
A value that changes after every action could be a request identifier, random data, a signature output, session data or a structure containing several components. Length and frequency of change help frame questions; they do not identify an algorithm by themselves.
Four useful levels of confidence
- Observation: a field is present in a sample, has a particular length or changes at a particular time.
- Standards-based interpretation: a public specification explains a field or structure.
- Hypothesis: an explanation fits the data but has not been isolated through testing.
- Finding within a defined scope: controlled comparisons and repeatable results support a conclusion.
Good research preserves the boundaries between these levels. "The value changed between two requests" is more defensible than "This is an HMAC signature that changes every second" when the latter lacks independent support.
2. Classifying headers: session state, context and custom fields
Do not put every header into a single "anti-bot" category. Different groups may serve different functions, and a request can involve several mechanisms at once.
| Group | Examples to identify | A useful research question |
|---|---|---|
| Content information |
Content-Type, Accept
|
What does the client send, and which response format does it expect? |
| Authentication |
Authorization, where the protocol uses it |
Which authentication scheme is involved? |
| Session state |
Cookie and application-specific session fields |
When was the session created, and which actions changed it? |
| Browser context |
Origin, Referer, Sec-Fetch-*
|
In which context did the request originate? |
| Application-specific fields |
af-ac-enc-dat, af-ac-enc-sz-token, x-sap-access-*
|
Where do these occur, and how do they relate to sessions and actions? |
| Response evidence | HTTP status, response headers and error codes in the body | Is the failure at the transport, HTTP or application layer? |
As MDN's Authorization documentation explains, the header carries credentials according to an authentication scheme. There is no single token format for all systems. A request without a Bearer token is therefore not necessarily a request without authentication.
The Cookie header sends relevant cookies from the client to the server. When comparing samples, record session state and the process that established it. Comparing only the final cookie strings can lose important context.
In browsers, Sec-Fetch-Site describes the relationship between the initiating origin and the destination. This is web-context information, not a universal requirement for native Android requests. Chrome's header set should not be the sole benchmark for an Android app.
How should Shopee-specific fields be interpreted?
| Field or group | What a sample can establish | What requires additional evidence |
|---|---|---|
af-ac-enc-dat |
Presence, size, character representation and changes between samples | Specific hardware fields inside it, encryption layers or key location |
af-ac-enc-sz-token |
Presence or absence, and when it appears relative to session establishment | Which component issues it, and its expiration or revocation rules |
x-sap-access-* |
Which members occur in a sample and whether they change together | The exact signing algorithm and which request components are bound to it |
Versions, platforms and endpoints do not necessarily use the same fields. Documentation should always identify the version and sample source. This table is a guide to interpreting evidence, not a decoder for private headers.
3. Tokens, signatures, encryption and Base64 are different concepts
A common mistake is to see a long string, decode it as Base64 and call the result "decrypted security data." Separate four concepts:
- Encoding: representing data in another form for transmission or storage.
- Encryption: protecting confidentiality through a cryptographic mechanism and keys.
- MACs and signatures: supporting authenticity or integrity checks, depending on the mechanism.
- Tokens: a role-based label; a token may be an opaque reference, structured data or cryptographically protected data.
Base64 in RFC 4648 is a data representation. Recovering bytes from a Base64 string does not establish their meaning or remove an encryption layer inside them. Hexadecimal strings can also represent many different kinds of data.
HMAC in RFC 2104 combines a secret key with a hash function for message authentication. Knowing what HMAC is does not establish that a particular Shopee header uses it. A fixed-length string can fit several different constructions.
An illustrative example: one change, several explanations
Consider a synthetic dataset used to practice analysis:
Sample A: request_id changes; field X changes; session_label stays the same
Sample B: request_id changes; field X changes; session_label stays the same
Sample C: a new session is created; X changes; session_label changes
This supports saying that X varies within a session and after a new session is created. It does not establish that X depends only on time, expires after three minutes or is signed using a particular algorithm. Those claims require additional observations or independent confirmation.
Claims such as "the token always contains an IMEI," "the key must be inside a TEE," or "the header expires after three to five minutes" remain unsupported by sufficient evidence in this research. Recording what is unknown improves the report; it does not reduce its value.
4. TLS, certificate authorities and certificate pinning
A useful conceptual breakdown is:
Connection establishment and transport protection
↓
Readable HTTP messages
↓
Authentication / session / operation validity
↓
Server-side application decision and response
This is an investigative model, not a diagram of Shopee's internal architecture. Success at one layer does not guarantee success at the next.
Capturing a PCAP does not mean reading HTTP
A PCAP records observed network packets. If application data travels inside TLS, collecting the bytes does not automatically provide the session secrets needed to decrypt it. With ephemeral key exchange, a PCAP is not simply a disguised JSON document that can be revealed through ordinary decoding. RFC 8446 describes TLS 1.3's key establishment and data protection.
CA trust and pinning are separate checks
Android Network Security Configuration describes how applications can select trust anchors and constrain accepted certificates or keys. Installing a CA on a device does not guarantee that every application trusts it; accepting a trust chain does not establish that a separate pinning constraint has been satisfied.
When a proxy-related failure occurs, classify it: was a connection established, did TLS complete, and did the application receive a response? An error icon alone does not identify a particular native library or the location of a certificate check.
Readable HTTP can still be rejected
The research notes include a session in which request and response data were readable while a login step still returned an error. This distinction matters: observability and permission to perform an operation are independent questions. Resolving visibility does not automatically resolve account state, session validity or server policy.
5. What do JA3 and JA4 TLS fingerprints tell us?
A TLS fingerprint summarizes aspects of how a client establishes a connection. Cloudflare's JA3/JA4 documentation explains their use in identifying and grouping clients by handshake characteristics, including JA4's normalization choices.
A fingerprint is not a unique identifier for an individual person or phone. Clients with similar configurations can share one. A client's connection characteristics can also change after software or networking changes.
The investigative implication is that "the browser and script have different fingerprints" does not establish "that difference alone caused the rejection." An appropriate control must isolate the factor. Cloudflare's documentation establishes that this technique exists in the industry; it does not establish that Shopee uses Cloudflare or a particular JA implementation in the observed case.
A careful finding would be: "The two environments produced different results and had different connection stacks; the effects of TLS, session state, network and application context have not yet been separated." This still guides further investigation without turning correlation into causation.
6. Bot detection: rules, behavior and risk scoring
An abuse-prevention system need not rely on one algorithm. Cloudflare's bot-detection engine documentation describes a combination of heuristics, client-side signals and machine learning, using information about requests, sessions and browsers.
Three conceptual models can help organize evidence:
| Model | How to think about it | What the evidence needs to answer |
|---|---|---|
| Rules and heuristics | A condition or combination of conditions leads to an action | Which conditions differ between accepted and rejected samples? |
| Sequence or behavioral analysis | Context includes several actions over time | Was the sequence and session history recorded completely? |
| Risk scoring | Several signals contribute to an assessment | Do server logs or other authoritative evidence confirm the score and decision? |
This table is a framework for analysis. It is not a reverse-engineered description of Shopee's detection algorithm. Without server-side data, we often observe only the outcome. Different mechanisms can produce the same verification screen.
Why might a "correct token" be insufficient?
In a hypothetical design, a token might establish only one property: that a session was created, a message was issued or a check occurred. Permission to perform the current operation is a separate question. Similar-looking values do not establish that a token can be transferred between contexts.
Why not infer detection thresholds from a few attempts?
Two successful attempts followed by a failure do not establish a three-request threshold. Timing, caching, session state, verification status and unobserved variables may also have changed. A report should state its sample size and observation window rather than turn a small count into a universal rule.
7. Device fingerprints and Play Integrity are not interchangeable
A device fingerprint combines signals that describe an environment. Device integrity is an assessment under a particular mechanism and set of conditions. The concepts are related but not interchangeable.
Google Play Integrity provides verdicts about application integrity, device environments and certain risky interactions. Its verdict documentation explains fields such as appIntegrity, deviceIntegrity and different device labels, whose requirements depend on the label and Android version.
A missing expected label does not automatically explain every application failure. An application may also use signals outside this service. The samples in this research do not include sufficient server-side verdict evidence to establish Play Integrity as the cause of the observed login rejection.
A phone succeeds and an emulator fails: what follows?
The defensible conclusion is that two test configurations produced different results. Hardware alone cannot be isolated if the network, app installation source, session state, operating system and account history also differ.
To strengthen a hypothesis, describe the similarities and differences, keep a group of conditions stable and record what cannot be controlled. Changing a displayed device model name does not establish equivalent integrity, networking or application behavior.
8. Shopee SG case study: what was actually observed?
The research notes from 15–16 October 2026 contain several concrete observations. Only a summary without credentials is published here; raw HAR files and tokens are not provided.
| Observation in the research notes | Supported finding | What it does not establish |
|---|---|---|
| Some test requests and responses could be read | A portion of the traffic was observable at an interpretable application level | Every protocol and endpoint had been analyzed |
An account-check step returned HTTP 418 and code 90309999
|
That operation did not complete normally in that sample | The code always means root, a bad IP address or an emulator |
| Another response returned HTTP 200 with an error in its body | HTTP status and application outcome must be read separately | HTTP 200 means the user successfully logged in |
| A review of an older HAR found 19 recommended-product cards | The older sample contained some product data | A complete PDP was captured for a product opened in a different test |
| A newer PCAP retained connection data, but the target product JSON was not readable | Candidate network streams remained available for further analysis | The product-detail request and response had been confirmed from ciphertext alone |
A particularly useful lesson is that reviewing evidence can change the scope of a conclusion. Before the older HAR was re-examined, saying "no product data has been obtained" was too broad. After finding recommendation cards, the better conclusion became: "Recommended-product card data exists in an older sample; the search or PDP flow under investigation remains unverified."
That correction is more useful than a general success claim. Recommendation, search and product-detail data may come through different flows. Finding a field in one response does not establish that other fields were obtained or that they share the same source.
Do not assign error-code meanings by guesswork
HTTP 403 indicates that a server refuses to fulfill a request. The status alone does not identify a specific cause. Platform-specific application codes require documentation or suitable controlled evidence before they can be mapped to causes.
In this case, the evidence does not establish a direct mapping between the UI label F13 and 90309999, or make either one conclusive proof of an IP or integrity problem. This remains an open question, not an identified algorithm.
9. A test matrix for isolating causes
Write the question before changing configurations. For example: "Does enabling the observation layer change the outcome of the same operation in the current configuration?" A small question makes the evidence requirements clearer.
| Observation axis | Minimum useful record | A design mistake to avoid |
|---|---|---|
| Application | Version, installation source, original or modified build | Changing the app build and network simultaneously |
| Device | OS, environment type and relevant configuration | Recording only a model name and omitting other changes |
| Network | Connection type, timing and connection changes | Attributing differences to IP when the session also changed |
| Session | New or continued session; verification state | Comparing a fresh session with a long-established one |
| Observation | Capture enabled or disabled; which layers are readable | Assuming every connection has the same decryption status |
| Outcome | UI result, HTTP status, application code and timestamp | Retaining only a screenshot or only an HTTP status |
A practical investigative sequence is:
- Establish a baseline: record the unchanged configuration's result for the specific operation.
- State the hypothesis: describe what should change if it is correct.
- Choose the variable: change one factor where possible, documenting exceptions.
- Align the timeline: associate the UI action with the correct timestamp and request/response.
- Compare layers: separate transport, HTTP and application differences.
- Repeat within bounds: record both failures and successes rather than selecting favorable samples.
- Define the finding: state what is supported, what has been ruled out and what evidence is missing.
These steps apply to environments and operations within an authorized testing scope. A useful report does not require high-volume traffic; the quality of controls often matters more than the number of requests.
An example test record
Test ID: LAB-EXAMPLE-01
Question: distinguish observation failures from application failures
Time: record timestamp and time zone
Application / OS: record actual versions
Session: new or continued; do not record raw tokens
Single change: describe explicitly
UI outcome: success / verification / error
HTTP and application code: record separately, if readable
Finding: limited to this configuration
Uncontrolled variables: list them rather than filling gaps with assumptions
This is an illustrative template, not a log from a real account or device.
10. Common mistakes in security-header analysis
Treating web and mobile clients as one protocol
Clients may follow different paths. The absence of a browser header in an app is not proof that the app is missing a required field. An app's behavior also does not establish that all web APIs behave identically.
Guessing internal structure from ciphertext
A long string does not reveal a schema. Start with representation, size and changes. If the serialization or encryption layer is unverified, label it "unknown" instead of assigning an algorithm name.
Mixing evidence from different sessions
A UI screenshot from session A, a HAR from session B and a product screenshot from session C can form a convincing but incorrect story. Each finding must reference the correct sample, timestamp and action.
Treating proxy visibility as the application's full view
Data may not pass through the observed component, may remain encrypted or may use a structure the tool cannot parse. A limitation of the observation tool is not a conclusion about the entire application.
Treating one success as a durable workflow
Describe a successful result under its actual conditions. A single sample does not establish long-term reliability, applicability to another account or suitability for a different purpose.
11. Frequently asked questions
What exactly does af-ac-enc-dat contain?
This research does not have a verified schema to publish. Characteristics can be catalogued from authorized samples, but the field name alone does not establish that it contains a specific hardware identifier.
Does copying cookies guarantee that a request will be accepted?
The samples in this article provide no such guarantee. Cookies form part of the session context; analysis should also consider how the session was established and which other conditions changed, rather than treating cookies as the client's entire state.
Why can HTTPS be readable while login still fails?
Readable data establishes visibility only for the observed flow. A server can still reject an operation because of session state, verification, permissions or application policy. Identifying the specific reason requires additional evidence.
Does Shopee definitely use JA4 or Play Integrity?
This article does not establish either claim for the tested sessions. Those technologies explain industry mechanisms and help formulate hypotheses; their public documentation is not evidence of Shopee's internal configuration.
Does error 90309999 mean the device has been blocked?
That conclusion cannot be drawn from the status or application code alone. The research notes do not provide an official mapping or controls sufficient to establish a device block, its duration or a single cause.
Can a complete PCAP immediately reveal JSON?
Not necessarily. Distinguish complete capture at the observation level from possession of session secrets, successful decryption and understanding the payload format. These are separate conditions.
Has this research reconstructed Shopee's anti-bot algorithm?
No. It provides a classification of security layers, bounded observations and a method for testing hypotheses. Knowing a few headers or error codes does not reconstruct the server's decision-making model.
12. Conclusions and references
Shopee security headers should be studied as part of a stateful system, not as a list of strings to copy. The lasting value is in locating the failure layer, maintaining evidence provenance and controlling variables in each comparison.
This approach also reflects Botslave's perspective on building systems: establish clarity before adding complexity, retain human ownership of important decisions and progress through steps that can be verified. Explore other notes in the Botslave Journal, or start a conversation about a research question.
Primary technical references
- MDN — Authorization: authentication schemes in HTTP.
- MDN — Cookie: cookies in requests.
- MDN — Sec-Fetch-Site: origin context for web requests.
- RFC 4648: Base16, Base32 and Base64.
- RFC 2104: the HMAC construction.
- RFC 8446: TLS 1.3's design.
- Android — Network Security Configuration: trust anchors and certificate pinning.
- Cloudflare — JA3/JA4: fingerprints at the TLS layer.
- Cloudflare — Bot detection engines: a public example of layered bot detection.
- Google — Play Integrity overview and Integrity verdicts: application and device assessments.
- MDN — 403 Forbidden: HTTP semantics, not a Shopee application-error catalogue.
Methodology and publication limits
Shopee-specific observations were checked against research notes from 15–16 October 2026. Published summaries exclude account information, cookies, tokens and device identifiers. Public references explain foundational mechanisms; they do not confirm Shopee's private algorithms. Server-side decision logs were not available to establish signal weights or detection thresholds.
Revision history — 21 October 2026: expanded the header classification, token and cryptography distinctions, detection layers, empirical evidence table, controlled-test matrix and FAQs. This English edition preserves the Vietnamese article's scope and uncertainty. Future evidence that changes a finding will be recorded as a revision rather than silently upgrading an earlier hypothesis into fact.
Originally published on botslave.com. Botslave is an automation studio — see what we build and how we work.
Top comments (0)