Gatsby Functions

What Gatsby Functions Are For

Gatsby Functions let a static Gatsby site execute backend logic at request time. That makes them useful when you need dynamic behaviour, such as handling form submissions, calling third-party APIs, or transforming data, without moving the whole application into a traditional always-on server model.

How Gatsby Functions Fit Into a Static Site Architecture

They sit alongside the frontend rather than inside the browser. In practice, that means the site can remain mostly static for speed and simplicity while still exposing small server-side entry points for specific tasks. This pattern is common when only a few parts of a site need computation, state changes, or controlled access to external services.

Because each function is deployed as an individual endpoint, the architecture is more granular than a single monolithic backend. That can make the application easier to split into clear responsibilities, but it also means the security boundary shifts to each exposed function and the data it accepts.

Security Implications of Serverless Endpoints

Although Gatsby Functions are developer-friendly, they still process untrusted input and may touch sensitive systems such as databases, payment services, or internal APIs. Their security posture depends on the same fundamentals as any other server-side endpoint, including authentication, authorization, input handling, logging, and secret protection.

The key difference from browser code is trust. Anything that runs server-side can protect secrets and perform privileged actions, but it can also become an abuse path if it is reachable without proper controls. Functions that proxy API requests or accept arbitrary parameters are especially important to review for excessive exposure.

Common Use Cases and Design Trade-offs

Gatsby Functions are best suited to small, request-driven tasks that complement a static site, not to large backend workflows. They work well for contact forms, lightweight integrations, webhook handling, and simple API mediation where the request path is narrow and the business logic is limited.

The trade-off is operational scope. Once a function starts carrying substantial business logic, complex state, or broad integration responsibilities, it begins to resemble a general serverless backend. At that point, teams should reassess whether the function still belongs inside the Gatsby application or whether a separate service would be easier to secure and maintain.

Risk and Threat Considerations

Gatsby Functions can expand a site’s attack surface because they expose backend logic through public endpoints, often with less operational visibility than a dedicated API service. The main risks are insecure input handling, broken access control, leaked secrets, and overexposed integrations that attackers can abuse through automated requests.

Failure mechanism: A function that assumes trusted input or relies on environment secrets without strict access checks can be invoked directly, turning a small utility endpoint into a data exposure or abuse path.

Impact: Exposure can include unauthorized actions, data leakage, abuse of third-party services, or compromise of connected systems if the function is used as a relay into higher-value assets.

Practitioner Guidance

Why practitioners should care: Treat each Gatsby Function as a separately exposed backend surface, not as an extension of the static frontend. That mental model helps teams apply the right controls to each endpoint instead of assuming static-site security is enough.

What to watch for: Review any function that accepts user input, calls external APIs, or uses secrets, because those are the points where authorization, validation, and secret handling matter most. If a function grows beyond a narrow task, consider moving the logic into a more explicit service boundary.

Related resources from NHI Mgmt Group

• Should organisations allow AI agents to call privileged MCP functions?
• Why do residency programmes often exempt authentication and control-plane functions?
• What should teams validate when policy languages add path functions?
• Who should approve access to sensitive application functions?