Member Avatar for BenVoigt

But, I am kind of wondering how common or how strongly perceived the risk is with having unobfuscated code lying around and getting it stolen.

Is there any literature on this? I have not found anything.

Edited by BenVoigt
  • 2 Contributors
  • 2 Replies
  • 96 Views
  • 10 Hours Discussion Span
  • Latest Post Latest Post by BenVoigt

Dani AI

Generated

A concise expert take linking the two earlier points from and : client-side assets can be harvested and used to reconstruct UI flows, API surfaces, and implementation assumptions; server-side source stays hidden, but the information an attacker can glean from HTML/CSS/JS often matters more than raw "code theft."

Things an attacker can learn from scraping client-side output:

  • API endpoints, HTTP verbs and expected parameters (useful for building automated clients).
  • Field names, data shapes and validation hints that reveal the model and attack surface.
  • Authentication and token patterns (refresh flows, cookie names) if implemented insecurely.
  • Hard-coded keys, debug comments, version strings or admin paths accidentally left in assets.
  • Predictable resource identifiers that enable Insecure Direct Object References (IDORs).

Practical defenses (prioritize server-side controls over obfuscation):

  • Never put secrets or authorization logic in client code; enforce authorization checks on every server endpoint.
  • Use short-lived tokens, rotate credentials, and avoid embedding keys in shipped assets.
  • Apply rate limits, CAPTCHAs or progressive challenges to suspicious crawls; monitor request patterns for headless clients or depth-first crawling.
  • Harden headers and resource policies: Content-Security-Policy and strict CORS reduce some abuse vectors (see MDN on CSP).
  • Treat minification/obfuscation as a deterrent only; do not rely on it for security.

Detection and follow-up:

  • Log and profile requests (high depth, low resource latency, unusual UA strings).
  • Use WAF/bot-management or CDN protections for heavy automated scraping (see Cloudflare on web scraping).
  • For business/IP concerns (UI/design copying), combine technical controls with legal remedies and monitoring.

For broader security context consult OWASP guidance on common web risks.

Recommended Answers

All 2 Replies

Member Avatar for hericles

What code you are referring to exactly? If you post up code on a webpage as a tutorial or similar then yes, it will get used by other people if its any good.
If you are referring to production code getting screen scraped I'm not sure how that would happen. Server side code can't be screen scraped as it isn't part of the page source. The only code that could be stolen like that is javascript but if you're worried about that then link to an external .js file rather than add javascript directly to the HTML.
Or have I missed th point of your post entirely?

Member Avatar for BenVoigt

No, I think you understood what I meant. But I was not referring to the server side code. Rather about the code that you have in the browser. Chances are js, css and similar files are not directly secured and can be retrieved along with the generated output, which is why you often get these "server-side" code snippets, too.

But I was concerned mainly because you could steal the entire nomenclature and topology of the website, and if you also look at the creation of the front-end dynamically by scraping series of browsed links, you could get a good picture of the states the website can be in, what they produce and use this to get a feeling for the back-end architecture. I mean, given the amount of time required to do that it is probably no a risk for most websites. But I still wonder if this is practiced in some cases.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.