[{"data":1,"prerenderedAt":169},["ShallowReactive",2],{"publication:en:P079":3},{"meta":4,"copy":17,"relatedArticles":139,"terms":161,"term":162,"resourceParent":163,"glossaryParent":166},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":15,"preparedOn":16},"P079","\u002Fblog\u002Fapi-keys-secrets","article","how to store API keys securely on a website","How to store API keys securely on a website and manage exposure","How to store API keys securely on a website","Distinguish public identifiers from secret API keys, review server and build exposure, limit permissions and plan supported rotation with integration checks.",[13,14],"\u002Fservices\u002Fcrm-integrations","\u002Fservices\u002Fsecurity-audit","2026-07-10","2026-10-30",{"intro":18,"sections":19,"checklistTitle":92,"checklist":93,"faq":101,"sources":111,"links":114,"cta":134},"Store secret API keys on the server or in a suitable managed secret store, with access limited to the application and authorized operators that need them. First confirm whether the provider designates a key as publishable or secret. A variable name, a hidden form field or a frontend build setting does not make a browser-delivered value confidential.",[20,29,34,74,82,87],{"title":21,"paragraphs":22,"sources":25},"Classify the credential before choosing its location",[23,24],"Identify the provider, account, environment and operations the credential authorizes. Some services intentionally provide public identifiers or publishable keys for client use; secret and restricted credentials have different handling requirements. Stripe's documentation makes this distinction for its own keys. Do not assume another provider uses the same labels, prefixes or permitted capabilities.","Record the credential's purpose without copying its value into the inventory. Include which component consumes it, who owns the provider account and what happens when the integration stops working. A secret used by a payment gateway, CRM or scheduled task can affect business operations even if no staff member signs in with it manually. Give each consumer an accountable owner before moving or rotating the credential.",[26],{"label":27,"url":28},"Stripe: publishable, secret and restricted API keys","https:\u002F\u002Fdocs.stripe.com\u002Fkeys",{"title":30,"paragraphs":31},"Trace server storage, build output and browser delivery separately",[32,33],"A backend runtime and a static frontend build have different visibility. A value substituted into downloadable JavaScript, rendered HTML, a public configuration object or a browser request can be observed by the client. An environment variable can still reach those outputs if the build or framework exposes it. Review the actual data path rather than the variable's name or the file extension that originally held it.","Inspect authorized configuration, generated artifacts and relevant logging behavior using safe methods. Avoid printing the secret into a terminal transcript or support report while checking whether it leaked. The finding can identify the location and credential reference without reproducing the value. Moving a secret to a server file only helps when that file, its access controls and the surrounding deployment keep it out of public delivery.",{"title":35,"paragraphs":36,"sources":39,"table":43},"Choose supported storage with restricted consumers and lifecycle control",[37,38],"OWASP's secrets guidance covers storage, access and lifecycle as connected responsibilities. A managed secret store can support controlled retrieval and auditing, but it still needs appropriate identities and configuration. Environment variables are not a universal secret-management boundary: they can appear in process access, diagnostics or deployment material. Use the supported arrangement that fits the actual platform and exposure requirements.","Limit each credential to required permissions and the intended environment where the provider supports it. Separate test and production consumers so a staging exercise does not act on live data. Keep ownership, retrieval and replacement procedures usable for the authorized operator. A sophisticated vault is not sufficient if every application receives a broad shared credential or nobody can operate recovery.",[40],{"label":41,"url":42},"OWASP: secret storage, lifecycle and exposure boundaries","https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FSecrets_Management_Cheat_Sheet.html",{"caption":44,"headers":45,"rows":49},"Secret location, consumer and rotation register",[46,47,48],"Field","Evidence to record","Acceptance question",[50,54,58,62,66,70],[51,52,53],"Classification","Provider-designated public or secret credential type.","Is client exposure actually permitted for this type?",[55,56,57],"Consumer","Application, job or integration and owner.","Does only the intended runtime receive it?",[59,60,61],"Storage and delivery","Supported server\u002Fstore path and access model.","Is it absent from public artifacts and unnecessary logs?",[63,64,65],"Permissions","Required operations and environment scope.","Can the credential do more than the approved job?",[67,68,69],"Exposure response","Provider controls and known dependent consumers.","Can misuse be limited while replacement is coordinated?",[71,72,73],"Replacement","Approved rollout and verification procedure.","Do legitimate functions work and old access end as intended?",{"title":75,"paragraphs":76,"example":79},"If exposure is suspected, address validity as well as visibility",[77,78],"Establish the affected credential, where it appeared and who is authorized to act. A secret removed from a public repository or page may still exist in history, cached artifacts or another person's copy. Restrict or revoke the credential using the provider's supported controls when appropriate, and coordinate the urgency with the exposure and business impact. Do not treat deleting the visible string as complete containment.","Preserve relevant evidence without spreading the secret. Review permitted provider logs and affected operations within the authorized incident scope. Lack of an obvious error is not proof that nobody used the credential. If a payment, customer-data or administrative operation may be affected, involve the accountable owner rather than handle the event as a cosmetic repository cleanup.",{"title":80,"text":81},"Illustrative frontend-variable exposure","A deployment variable is labeled private but substituted into the browser bundle. The source setting looks protected while the delivered value is public. The owner reviews credential validity and consumer scope as well as correcting the build path.",{"title":83,"paragraphs":84},"Rotate through the provider’s procedure and verify every consumer",[85,86],"Plan the supported replacement, affected applications and acceptance checks before ordinary maintenance rotation. Providers differ in immediate invalidation, overlap and endpoint-specific secrets. Do not promise a universal grace period or assume changing one dashboard value updates every server, worker and integration. For suspected misuse, containment urgency may require a different sequence from routine rotation.","Test the supported replacement in an appropriate environment, deploy through the authorized process and verify required business operations. Then confirm the old credential's intended status and record any consumers still using it. Keep private values out of the handover; record references, ownership and the evidence of successful operation instead. A successful homepage load says little about a background CRM export or scheduled billing job.",{"title":88,"paragraphs":89},"Maintain the inventory through development and supplier changes",[90,91],"Review credentials when an integration, developer, deployment system or supplier changes. Ensure the business controls the provider account and can replace access without relying on a former contractor's personal account. Remove obsolete consumers and review permissions, while confirming that legitimate jobs and notifications still function. The credential register should remain useful after the original developer leaves.","CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with practical Israeli knowledge of websites, integrations and digital infrastructure. We can scope credential-path review, supported configuration and coordinated replacement with the application owner. The handover explains ownership, accepted operation and remaining exposure questions without requesting secrets in an ordinary enquiry.","API credential handling acceptance",[94,95,96,97,98,99,100],"Public versus secret type confirmed with the provider","Account, environment, purpose and consumers mapped","Server\u002Fstore access limited to approved identities","Public bundles, configuration and unnecessary logs reviewed","Test and production credential paths distinguished","Exposure and replacement actions follow provider support","All affected business consumers checked after change",[102,105,108],{"question":103,"answer":104},"Can a secret API key be hidden in frontend JavaScript?","Treat values delivered to a browser as observable by that client. Encoding, renaming or minifying the key does not create confidentiality. Use the provider’s supported backend model for secret operations and only intentionally publishable credentials in client code.",{"question":106,"answer":107},"Is an environment variable automatically secure?","No: review where it is read, whether a build exposes it and who can inspect the runtime or diagnostics. Choose suitable supported storage and access controls; a variable name does not establish a secret boundary.",{"question":109,"answer":110},"Does removing a leaked key from Git finish the response?","Not necessarily: copies may remain in history or elsewhere, and the credential may still be valid. Use the authorized provider controls, assess relevant activity and coordinate replacement for legitimate consumers without reproducing the secret in reports.",[112,113],{"label":27,"url":28},{"label":41,"url":42},[115,117,120,123,126,129,131],{"path":13,"label":116},"Scope application and CRM integration work",{"path":118,"label":119},"\u002Fglossary\u002Fleast-privilege","Limit credential capabilities to the task",{"path":121,"label":122},"\u002Fblog\u002Fwebhook-security","Review signing secrets and callback processing",{"path":124,"label":125},"\u002Fblog\u002Fwp-staging-vs-production","Separate test and production integration paths",{"path":127,"label":128},"\u002Fblog\u002Femployee-offboarding-access","Review credentials during a departure",{"path":14,"label":130},"Scope an authorized exposure review",{"path":132,"label":133},"\u002Fblog\u002Fdocker-security-checklist","Review container secret and daemon boundaries",{"title":135,"description":136,"button":137,"type":138},"Review where the integration’s secret actually travels","Describe the provider, application and concern without sending the key. We can agree the consumer map and supported next steps.","Discuss API credential security","check",[140,147,154],{"id":141,"path":121,"title":142,"description":143,"category":144,"artwork":144,"order":145,"publishedOn":146},"P080","Webhook security checklist: verify events and business effects","Review webhook signatures, request bytes, replay and duplicate handling, event scope and durable processing. Test the business result with synthetic events.","integrations",86,"2026-06-24",{"id":148,"path":149,"title":150,"description":151,"category":144,"artwork":144,"order":152,"publishedOn":153},"P196","\u002Fblog\u002Fthird-party-script-data-flow","Third party script data privacy: inspect the actual browser data flow","Map third party scripts, tag managers and browser data flows. Distinguish CSP, integrity and consent checks, then test approved changes with synthetic data.",77,"2026-06-08",{"id":155,"path":156,"title":157,"description":158,"category":144,"artwork":144,"order":159,"publishedOn":160},"P119","\u002Fblog\u002Fapi-security-business-checklist","API security checklist for business integrations","Review API identities, record and action permissions, resource limits, secrets and webhooks. Define controlled acceptance with synthetic accounts and data.",69,"2026-05-23",[],null,{"path":164,"label":165},"\u002Fresources","Website security resources and templates",{"path":167,"label":168},"\u002Fglossary","Cybersecurity glossary for small businesses",1794134059059]