When you enumerate entry points on a data-flow diagram, what counts as one?
answer
- not only the HTTP routes
- data can arrive with nobody waiting
- queues, file drops, inbound mail
- an internal trigger, external content
- staff and support paths count too
basics
~20 sAn entry point is anywhere data or a request crosses into the system from outside its trust boundary. Not just HTTP endpoints: queue consumers, file drops, inbound email, webhooks, scheduled jobs that fetch remote data, and admin or support consoles all count.
solid answer
~50 sAn entry point is any place where something from outside the trust boundary reaches code inside it. The usual mistake is to list only the synchronous request paths a user clicks. Take a local-authority housing-benefit system: the public claim form is one entry point, but so is the nightly SFTP drop from a bank, the email-to-case gateway that turns an inbound message into a case, and the 3am reconciliation job that pulls a remote file and parses it. Add the staff-facing paths — the caseworker console, the support tool that lets an agent act as a claimant, and the batch upload a back-office team uses. Each of those accepts data chosen by someone outside, and each is a place the attacker gets to speak. If a flow on the diagram crosses a boundary inward, it is an entry point regardless of protocol, schedule or audience.
go deeper
Be ready to define an entry point as any inbound crossing of a trust boundary, and to name at least three that are not HTTP: a queue consumer, a file drop and an inbound email gateway.
Explain why an internally triggered job still counts when it pulls remote data, and why the response to your own outbound call re-enters the boundary. Show the mechanics, not just the list.
Demonstrate that you can enumerate exhaustively on a whiteboard by walking actors and external systems rather than routes, and that you reach for the administrative and support paths without being prompted.
Own the question of granularity and upkeep: what counts as one entry point across hundreds of routes, and how the inventory stays true as teams add integrations you never reviewed.
## What the term means An **entry point** is a place where data or control crosses *into* the system you are modeling, from outside its trust boundary. That definition is deliberately protocol-agnostic. On a data-flow diagram it is simply any arrow that crosses a boundary line pointing inward, plus the process that receives it. The reason threat modeling starts here is that an attacker cannot influence your system except through an entry point: the inventory of entry points is the inventory of places the adversary is allowed to speak, and anything not on that list is a place you are implicitly claiming they cannot reach. Note the vocabulary carefully. An entry point is not a vulnerability and not a threat. It is a *feature of the design*: the claim form is supposed to accept claims. What it gives you is a place to stand when you later ask what could go wrong there. ## The categories teams actually forget Most teams produce a list of HTTP routes and stop. A usable inventory has at least these families: - **Synchronous request paths.** Public web and mobile APIs, the browser app, partner APIs. These get listed; they are rarely the interesting part of the exercise. - **Asynchronous ingestion.** Queue and topic consumers, event subscriptions, webhook receivers. The data arrives with no human waiting, often into code with fewer checks than the front door, and frequently with an implicit assumption that "it came off our own queue, so it is ours". - **File and batch drops.** An SFTP landing directory, a shared bucket a partner writes to, an operator-uploaded spreadsheet. Whoever can write the file chooses the bytes your parser sees. - **Inbound mail and messaging.** An email-to-case or email-to-ticket gateway is an anonymous, unauthenticated entry point with attachments, and it is almost never on the first draft of the diagram. - **Scheduled jobs that pull.** A 3am reconciliation job looks internal because *you* start it, but if it fetches a remote file or calls a third-party API, the remote side chooses the content. The trigger is internal; the data is not. - **Responses to your own outbound calls.** When your service calls an upstream API, the reply re-enters your boundary and is parsed by your code. A compromised or impersonated upstream is an entry point. - **Configuration and control planes.** Feature-flag reads, remote config, a plugin or template pulled at runtime. Whoever can change the flag changes your behaviour without touching your source. - **Human and administrative paths.** Admin consoles, support impersonation, back-office bulk tools, the deploy pipeline, and break-glass access. These carry the most privilege and the least traffic, which is exactly why they are skipped. ## Worked inventory For the housing-benefit system, a first-pass table looks like this — note that it records *who can reach it* rather than just naming a URL: | Entry point | Who can reach it | What it can do | | --- | --- | --- | | Public claim form | Anyone on the internet, unauthenticated | Create a claim, upload evidence documents | | Caseworker console | Staff with SSO, on the corporate network | Read and amend any claim, approve payments | | Bank SFTP drop | The bank's automation, or anyone who compromises it | Feed the payment reconciliation file | | Email-to-case gateway | Anyone who knows the address | Create or append to a case, attach files | | 3am reconciliation job | The remote source it pulls from | Supply the records the job parses and applies | | Support impersonation tool | A named support agent | Act as any claimant | The adversaries differ per row — an anonymous claimant at the form, a compromised bank feed at the SFTP drop, a malicious or phished insider at the console — and so do the assets at stake: claimant personal data at the form, public money at the reconciliation path. ## How to keep the list finishable Enumerate at the granularity of *distinct trust relationships*, not URLs. Two hundred routes behind the same authentication, the same authorization model and the same handler stack are one entry point for modeling purposes; the one route that is exempt from that authentication is a separate entry point even though it is a single line of config. Group by "who may reach this, and what identity do they carry", and the list stays short enough to reason about while still surfacing the exceptions, which are where the interesting threats live. A good sanity check before you call the list complete: walk each *actor* on the diagram and ask how they get data in, then walk each *external system* and ask the same. Actors and systems are easier to enumerate exhaustively than interfaces, and they drag the forgotten asynchronous and administrative paths onto the page.
- A scheduled job runs entirely inside your network. Why would you still list it as an entry point?Because the trigger being internal says nothing about the data. If the job fetches a remote file, calls a third-party API or reads a partner's bucket, the content it parses is chosen outside your boundary. The schedule is yours; the bytes are the remote party's, and that is what makes it an entry point.
- Is the response to an outbound call you made an entry point?Yes. The call is egress, but the response crosses back in and is deserialised, parsed and often trusted by your code. A compromised, impersonated or simply misbehaving upstream feeds you data on that path. Model it as an inbound flow with the upstream as the actor who controls the content.
- How do you stop the enumeration from turning into a list of every URL?Group by trust relationship rather than by route. Routes that share an authentication mechanism, an authorization model and a handler stack collapse into one entry point; any route that is exempt from that mechanism becomes its own entry, however small. The exceptions are what the exercise is for.
A building's entry points are not just the front door: the loading bay, the mail slot, the contractor's key and the delivery scheduled for 3am all let something chosen by an outsider inside.
saying these in an interview costs you the question
- Lists only public HTTP endpoints and calls the surface complete
- Treats a queue as internal, so not an entry point
- Assumes a scheduled job has no external input
- Leaves out admin, support and back-office paths
- Enumerates every URL and never finishes the list