साइट को सार्वजनिक करने से पहले वेब एप्लिकेशन के प्रोग्रामर को क्या तकनीकी जानकारी पर विचार करना चाहिए?

Question

साइट को सार्वजनिक करने से पहले एक वेब एप्लिकेशन के तकनीकी विवरण को लागू करने वाले प्रोग्रामर को किन चीजों पर विचार करना चाहिए? अगर जेफ एटवुड के बारे में भूल कर सकते हैं कुकीज़ केवल Http , साइटमैप , और क्रॉस साइट अनुरोध जालसाजियों एक ही साइट में सब , क्या महत्वपूर्ण बात यह है मैं भी भूल जा सकता है?

मैं वेब डेवलपर के दृष्टिकोण से इस बारे में सोच रहा हूं, जैसे कि कोई और साइट के लिए वास्तविक डिजाइन और सामग्री बना रहा है। इसलिए जब प्रयोज्य और सामग्री प्लेटफ़ॉर्म से अधिक महत्वपूर्ण हो सकती है, तो आप प्रोग्रामर को बहुत कम कहते हैं। आपको इस बारे में चिंता करने की ज़रूरत है कि प्लेटफ़ॉर्म का आपका कार्यान्वयन स्थिर है, अच्छा प्रदर्शन करता है, सुरक्षित है, और किसी भी अन्य व्यावसायिक लक्ष्यों को पूरा करता है (जैसे कि बहुत अधिक लागत नहीं, निर्माण के लिए बहुत लंबा समय लेना चाहिए, और Google के साथ ही रैंक करना चाहिए सामग्री का समर्थन करता है)।

एक ऐसे डेवलपर के दृष्टिकोण से सोचें, जिसने काफी भरोसेमंद माहौल में इंट्रानेट-प्रकार के अनुप्रयोगों के लिए कुछ काम किया है, और वह अपना पहला शॉट लगाने वाला है और पूरे बड़े बुरे वर्ल्ड वाइड वेब के लिए संभावित रूप से लोकप्रिय साइट को बाहर कर रहा है।

इसके अलावा, मैं सिर्फ एक अस्पष्ट "वेब मानकों" की प्रतिक्रिया की तुलना में अधिक विशिष्ट चीज की तलाश कर रहा हूं। मेरा मतलब है, HTTP पर HTML, जावास्क्रिप्ट और CSS बहुत अधिक दिए गए हैं, खासकर जब मैंने पहले ही निर्दिष्ट किया है कि आप एक पेशेवर वेब डेवलपर हैं। तो इससे आगे बढ़कर कौन से मानक हैं? किन परिस्थितियों में, और क्यों? मानक के विनिर्देश के लिए एक लिंक प्रदान करें।

Answer 1

विचार है कि यहाँ हम में से ज्यादातर चाहिए पहले से ही पता है कि सबसे क्या इस सूची में है की। लेकिन वहाँ सिर्फ एक या दो आइटम हो सकते हैं जिन्हें आपने वास्तव में पहले नहीं देखा था, पूरी तरह से समझ में नहीं आया, या शायद कभी भी नहीं सुना।

इंटरफ़ेस और उपयोगकर्ता अनुभव

• ध्यान रखें कि ब्राउज़र असंगत तरीके से मानकों को लागू करते हैं और सुनिश्चित करते हैं कि आपकी साइट सभी प्रमुख ब्राउज़रों में यथोचित कार्य करती है। हाल ही में गेको इंजन ( फ़ायरफ़ॉक्स ), एक वेबकिट इंजन ( सफारी और कुछ मोबाइल ब्राउज़र), क्रोम , आपके समर्थित IE ब्राउज़रों ( एप्लिकेशन संगतता VPC छवियाँ का लाभ उठाएं ) और ओपेरा के खिलाफ न्यूनतम परीक्षण में । यह भी विचार करें कि ब्राउज़र विभिन्न ऑपरेटिंग सिस्टम में आपकी साइट को कैसे प्रस्तुत करता है।
• इस बात पर विचार करें कि लोग प्रमुख ब्राउज़रों से अलग साइट का उपयोग कैसे कर सकते हैं: सेल फोन, स्क्रीन रीडर और खोज इंजन, उदाहरण के लिए। - कुछ पहुंच जानकारी: WAI और Section508 , मोबाइल विकास: MobiForge ।
• स्टेजिंग: अपने उपयोगकर्ताओं को प्रभावित किए बिना अपडेट कैसे तैनात करें। आर्किटेक्चर, कोड या स्वीपिंग सामग्री में परिवर्तन को लागू करने के लिए एक या अधिक परीक्षण या स्टेजिंग वातावरण उपलब्ध हैं और यह सुनिश्चित करें कि उन्हें कुछ भी तोड़कर नियंत्रित तरीके से तैनात किया जा सके। लाइव साइट पर स्वीकृत परिवर्तनों को लागू करने का एक स्वचालित तरीका है। यह एक संस्करण नियंत्रण प्रणाली (गिट, तोड़फोड़, आदि) और एक स्वचालित निर्माण तंत्र (एंट, एनएएनटी, आदि) के उपयोग के साथ संयोजन के रूप में सबसे प्रभावी ढंग से लागू किया गया है।
• सीधे उपयोगकर्ता के लिए अमित्र त्रुटियों को प्रदर्शित न करें।
• सादे पाठ में उपयोगकर्ताओं के ईमेल पते न डालें क्योंकि वे मृत्यु के लिए स्पैम हो जाएंगे।
• स्पैम से बचने केrel="nofollow" लिए उपयोगकर्ता-जनरेट लिंक की विशेषता जोड़ें ।
• अपनी साइट में अच्छी तरह से मानी जाने वाली सीमाओं का निर्माण करें - यह भी सुरक्षा के अंतर्गत आता है।
• प्रगतिशील वृद्धि करना सीखें ।
• एक POST के बाद पुनर्निर्देशित करें यदि वह POST सफल था, एक ताज़ा को फिर से जमा करने से रोकने के लिए।
• खाते में एक्सेसिबिलिटी लेना न भूलें। यह हमेशा एक अच्छा विचार है और कुछ परिस्थितियों में यह एक कानूनी आवश्यकता है । WAI-ARIA और WCAG 2 इस क्षेत्र में अच्छे संसाधन हैं।
• पढ़ें मुझे मत सोचो ।

सुरक्षा

• यह पचाने के लिए बहुत कुछ है लेकिन OWASP विकास मार्गदर्शिका ऊपर से नीचे तक वेब साइट सुरक्षा को कवर करती है।
• जानिए इंजेक्शन के बारे में विशेष रूप से SQL इंजेक्शन और इसे कैसे रोकें।
• उपयोगकर्ता इनपुट पर कभी भी भरोसा न करें, और न ही अनुरोध में आने वाली कोई भी चीज़ (जिसमें कुकीज़ और छिपे हुए फ़ॉर्म फ़ील्ड मान शामिल हों!)।
• नमक का उपयोग करके पासवर्ड को हैश करें और इंद्रधनुष के हमलों को रोकने के लिए अपनी पंक्तियों के लिए विभिन्न लवणों का उपयोग करें। पासवर्ड को स्टोर करने के लिए धीमी गति से हैशिंग एल्गोरिथ्म का उपयोग करें, जैसे कि bcrypt (समय परीक्षण) या scrypt (और भी मजबूत, लेकिन नया) ( 1 , 2 )। ( कैसे सुरक्षित रूप से एक पासवर्ड स्टोर )। NIST भी पासवर्ड हैश करने के लिए PBKDF2 की मंजूरी दी ", और यह की FIPS .NET में मंजूरी दे दी है (अधिक जानकारी यहाँ )। बचें सीधे MD5 या SHA परिवार के प्रयोग से।
• अपने स्वयं के फैंसी प्रमाणीकरण प्रणाली के साथ आने की कोशिश न करें । सूक्ष्म और अनछुए तरीकों से गलत हो जाना इतनी आसान बात है और आपके हैक होने के बाद आपको इसका पता भी नहीं चलेगा ।
• क्रेडिट कार्ड के प्रसंस्करण के नियमों को जानें । ( इस सवाल को भी देखें )
• उन साइटों के लिए SSL / TLS / HTTPS का उपयोग करें जहां संवेदनशील डेटा दर्ज किया गया है (जैसे क्रेडेंशियल, व्यक्तिगत रूप से पहचान योग्य जानकारी, क्रेडिट कार्ड की जानकारी)। आइए एनक्रिप्ट एक निःशुल्क प्रमाण पत्र प्राधिकरण है जो मदद कर सकता है।
• सत्र अपहरण को रोकें ।
• क्रॉस साइट स्क्रिप्टिंग (XSS) से बचें ।
• क्रॉस साइट अनुरोध forgeries (CSRF) से बचें ।
• क्लिकजैकिंग से बचें ।
• नवीनतम पैच के साथ अपना सिस्टम रखें।
• सुनिश्चित करें कि आपके डेटाबेस कनेक्शन की जानकारी सुरक्षित है।
• अपने मंच को प्रभावित करने वाली नवीनतम हमले तकनीकों और कमजोरियों के बारे में खुद को सूचित रखें।
• Google ब्राउज़र सुरक्षा पुस्तिका पढ़ें ।
• वेब एप्लिकेशन हैकर की हैंडबुक पढ़ें ।
• कम से कम विशेषाधिकार के सिद्धांत पर विचार करें । अपने ऐप सर्वर को नॉन-रूट के रूप में चलाने का प्रयास करें । ( टॉमकैट उदाहरण )
• रखो rel="noopener noreferrer"के साथ सभी उपयोगकर्ता के दिए गए लिंक्स पर target="_blank"अपने पेज में इस तरह के एक नकली लॉगिन पृष्ठ के रूप में, कहीं और के लिए पुनः निर्देशित से गंतव्य पृष्ठ पर मौजूद JavaScript को रोकने के लिए। और जानकारी
• एक सख्त सामग्री सुरक्षा नीति का उपयोग करने पर विचार करें ।

प्रदर्शन

• यदि आवश्यक हो, तो कैशिंग को लागू करें और समझें कि एचटीटीपी कैशिंग के साथ-साथ एचटीएमएल 5 मेनिफेस्ट का भी सही उपयोग करें ।
• छवियों को ऑप्टिमाइज़ करें - दोहराई गई पृष्ठभूमि के लिए 20 KB की छवि का उपयोग न करें।
• गति के लिए सामग्री को संपीड़ित करें, ब्रेटली , गज़िप / डिफ्लेट ( डिफ्लेट बेहतर है ) देखें।
• ब्राउज़र कनेक्शन की संख्या को कम करने और फ़ाइलों के बीच दोहराव को कम करने के लिए gzip क्षमता में सुधार करने के लिए कई स्टाइलशीट या एकाधिक स्क्रिप्ट फ़ाइलों को मिलाएं / संक्षिप्त करें।
• Yahoo असाधारण प्रदर्शन साइट पर नज़र डालें , बहुत सारे महान दिशानिर्देश, जिनमें फ्रंट-एंड प्रदर्शन और उनके YSlow टूल (फ़ायरफ़ॉक्स, सफारी, क्रोम या ओपेरा की आवश्यकता है) को बेहतर बनाना शामिल है। इसके अलावा, Google पृष्ठ गति ( ब्राउज़र एक्सटेंशन के साथ उपयोग ) प्रदर्शन रूपरेखा के लिए एक और उपकरण है, और यह आपकी छवियों को भी अनुकूलित करता है।
• टूलबार जैसी छोटी संबंधित छवियों के लिए CSS छवि स्प्राइट्स का उपयोग करें ("HTTP अनुरोधों को कम करें" बिंदु देखें)
• एसवीजी छवि स्प्राइट्स का उपयोग टूलबार जैसी छोटी संबंधित छवियों के लिए करें । एसवीजी रंग थोड़ा मुश्किल है। आप इसके बारे में यहां पढ़ सकते हैं ।
• व्यस्त वेब साइटों को डोमेन में विभाजन घटकों पर विचार करना चाहिए । विशेष रूप से ...
• स्टेटिक कंटेंट (यानी इमेज, सीएसएस, जावास्क्रिप्ट और आमतौर पर कुकीज़ तक पहुंचने की आवश्यकता नहीं है) को एक अलग डोमेन में जाना चाहिए जो कुकीज़ का उपयोग नहीं करता है , क्योंकि एक डोमेन और उसके सबडोमेन के लिए सभी कुकीज़ को हर अनुरोध के साथ भेजा जाता है। डोमेन और उसके उप डोमेन। यहां एक अच्छा विकल्प एक कंटेंट डिलीवरी नेटवर्क (सीडीएन) का उपयोग करना है, लेकिन उस मामले पर विचार करें जहां सीडीएन वैकल्पिक सीडीएन, या स्थानीय प्रतियों को शामिल करके विफल हो सकता है जिन्हें इसके बजाय परोसा जा सकता है।
• पृष्ठ को रेंडर करने के लिए ब्राउज़र के लिए आवश्यक HTTP अनुरोधों की कुल संख्या कम से कम करें।
• टेम्प्लेट इंजन चुनें और टास्क-रनर्स जैसे गल्प या ग्रंट का उपयोग करके इसे प्री-कंपाइल करें
• सुनिश्चित करें कि favicon.icoसाइट की जड़ में एक फ़ाइल है, अर्थात /favicon.ico। अगर ब्राउज़र HTML में बिल्कुल भी अंकित नहीं है, तो ब्राउजर अपने आप इसे रिक्वेस्ट करेगा । यदि आपके पास नहीं है /favicon.ico, तो यह आपके सर्वर की बैंडविड्थ को खत्म करते हुए, 404s के बहुत से परिणाम देगा।

एसईओ (खोज इंजन अनुकूलन)

• "खोज इंजन के अनुकूल" URL का उपयोग करें, अर्थात example.com/pages/45-article-titleइसके स्थान पर उपयोग करेंexample.com/index.php?page=45
• जब #डायनेमिक कंटेंट के लिए उपयोग किया #जाता है #!तो सर्वर पर बदल जाता है और $_REQUEST["_escaped_fragment_"]इसके बजाय googlebot उपयोग करता है #!। दूसरे शब्दों में, ./#!page=1बन जाता है ./?_escaped_fragments_=page=1। इसके अलावा, उन उपयोगकर्ताओं के लिए जो FF.b4 या क्रोमियम का उपयोग कर रहे हैं, history.pushState({"foo":"bar"}, "About", "./?page=1");एक बढ़िया कमांड है। भले ही पता बार बदल गया हो, पृष्ठ फिर से लोड नहीं होता है। यह आपको गतिशील सामग्री रखने के ?बजाय उपयोग करने की अनुमति देता #!है और सर्वर को यह भी बताता है कि आप इस पेज के बाद आने वाले लिंक को ईमेल करते हैं, और AJAX को एक और अतिरिक्त अनुरोध करने की आवश्यकता नहीं है।
• "यहां क्लिक करें" कहने वाले लिंक का उपयोग न करें । आप एक एसईओ अवसर को बर्बाद कर रहे हैं और यह स्क्रीन रीडर वाले लोगों के लिए चीजों को कठिन बनाता है।
• एक है एक्सएमएल साइटमैप , अधिमानतः डिफ़ॉल्ट स्थान में /sitemap.xml।
• का प्रयोग करें <link rel="canonical" ... />यदि आप एकाधिक URL कि एक ही सामग्री पर किए हैं, तो इस समस्या को भी से संबोधित किया जा सकता गूगल वेबमास्टर उपकरण ।
• Google वेबमास्टर टूल और बिंग वेबमास्टर टूल का उपयोग करें ।
• शुरुआत में गूगल एनालिटिक्स को स्थापित करें (या पिविक की तरह एक खुला स्रोत विश्लेषण उपकरण )।
• जानिए कैसे robots.txt और सर्च इंजन स्पाइडर काम करते हैं।
• दोनों साइटों के बीच Google रैंकिंग को विभाजित करने से रोकने 301 Moved Permanentlyके www.example.comलिए example.com(या दूसरे तरीके से ) अनुरोध को पुनर्निर्देशित (उपयोग करके ) ।
• पता है कि वहाँ बुरी तरह से मकड़ियों का व्यवहार किया जा सकता है।
• यदि आपके पास गैर-पाठ सामग्री है, तो वीडियो आदि के लिए Google के साइटमैप एक्सटेंशन पर ध्यान दें । टिम फार्ले के उत्तर में इसके बारे में कुछ अच्छी जानकारी है ।

प्रौद्योगिकी

• HTTP और GET, POST, सत्र, कुकीज और चीजों को समझें और इसका अर्थ "स्टेटलेस" होना है।
• W3C विनिर्देशों के अनुसार अपने XHTML / HTML और CSS लिखें और सुनिश्चित करें कि वे मान्य हैं । यहां लक्ष्य ब्राउज़र क्वर्क्स मोड से बचना है और बोनस के रूप में स्क्रीन रीडर और मोबाइल डिवाइस जैसे गैर-पारंपरिक ब्राउज़र के साथ काम करना बहुत आसान है।
• समझें कि ब्राउज़र में जावास्क्रिप्ट को कैसे संसाधित किया जाता है।
• यह समझें कि जावास्क्रिप्ट, शैली पत्रक, और आपके पृष्ठ द्वारा उपयोग किए जाने वाले अन्य संसाधन कैसे भरे हुए हैं और कथित प्रदर्शन पर उनके प्रभाव पर विचार करते हैं । अब यह व्यापक रूप से उपयुक्त माना जाता है कि लिपियों को आपके पृष्ठों के निचले भाग में ले जाना अपवाद के रूप में आमतौर पर एनालिटिक्स ऐप या एचटीएमएल 5 शिम जैसी चीजें हैं।
• यह समझें कि जावास्क्रिप्ट सैंडबॉक्स कैसे काम करता है, खासकर यदि आप आइफ्रेम का उपयोग करने का इरादा रखते हैं।
• ध्यान रखें कि जावास्क्रिप्ट को अक्षम किया जा सकता है, और यह कि AJAX इसलिए एक विस्तार है, न कि आधारभूत। यहां तक ​​कि अगर अधिकांश सामान्य उपयोगकर्ता अब इसे छोड़ देते हैं, तो याद रखें कि NoScript अधिक लोकप्रिय हो रहा है, मोबाइल डिवाइस उम्मीद के मुताबिक काम नहीं कर सकते हैं, और साइट को अनुक्रमित करते समय Google आपके अधिकांश जावास्क्रिप्ट को नहीं चलाएगा।
• 301 और 302 रीडायरेक्ट के बीच अंतर जानें (यह भी एक एसईओ मुद्दा है)।
• अपने तैनाती मंच के बारे में जितना संभव हो उतना जानें।
• रीसेट स्टाइल शीट या normalize.css का उपयोग करने पर विचार करें ।
• जावास्क्रिप्ट फ्रेमवर्क पर विचार करें (जैसे कि jQuery , MooTools , प्रोटोटाइप , Dojo या YUI 3 ), जो DOM हेरफेर के लिए जावास्क्रिप्ट का उपयोग करते समय बहुत सारे ब्राउज़र अंतर छिपाएगा।
• कथित प्रदर्शन और जेएस फ्रेमवर्क को एक साथ लेते हुए, फ्रेमवर्क को लोड करने के लिए Google लाइब्रेरी API जैसी सेवा का उपयोग करने पर विचार करें ताकि एक ब्राउज़र आपकी साइट से डुप्लिकेट कॉपी डाउनलोड करने के बजाय पहले से कैश की गई रूपरेखा की प्रतिलिपि का उपयोग कर सके।
• पहिया को सुदृढ़ मत करो। कुछ भी करने से पहले एक घटक या उदाहरण के लिए खोज करें कि यह कैसे करना है। 99% संभावना है कि किसी ने इसे किया है और कोड का एक ओएसएस संस्करण जारी किया है।
• इससे पहले कि आप अपनी जरूरतों के हिसाब से तय कर लें, उसके पहले ही 20 पुस्तकालयों से शुरू न करें। विशेष रूप से क्लाइंट-साइड वेब पर जहां यह लगभग हमेशा अधिक महत्वपूर्ण होता है कि चीजों को हल्का, तेज और लचीला रखें।

बग फिक्सिंग

• समझें कि आप अपना 20% समय कोडिंग और इसे बनाए रखने का 80% खर्च करेंगे, इसलिए तदनुसार कोड।
• एक अच्छी त्रुटि रिपोर्टिंग समाधान सेट करें।
• लोगों को सुझाव और आलोचनाओं के साथ संपर्क करने के लिए एक प्रणाली रखें।
• दस्तावेज़ कैसे भविष्य के सहायक कर्मचारियों और रखरखाव करने वाले लोगों के लिए काम करता है।
• लगातार बैकअप लें! (और सुनिश्चित करें कि वे बैकअप कार्यात्मक हैं) एक पुनर्स्थापना रणनीति है, न कि केवल एक बैकअप रणनीति।
• अपनी फ़ाइलों को संग्रहीत करने के लिए एक संस्करण नियंत्रण प्रणाली का उपयोग करें, जैसे कि सबवर्सन , मर्क्यूरियल या गिट ।
• अपनी स्वीकृति परीक्षण करने के लिए मत भूलना। सेलेनियम जैसे फ्रेमवर्क मदद कर सकते हैं। खासकर यदि आप अपने परीक्षण को पूरी तरह से स्वचालित करते हैं, तो शायद एक निरंतर एकीकरण उपकरण का उपयोग करके, जैसे कि जेनकिंस ।
• सुनिश्चित करें कि आपके पास log4j , log4net या log4r जैसे चौखटे का उपयोग करके पर्याप्त जगह है । यदि आपकी लाइव साइट पर कुछ गलत होता है, तो आपको यह पता लगाने के तरीके की आवश्यकता होगी।
• जब लॉगिंग सुनिश्चित करें कि आप दोनों संभाला अपवादों को पकड़ते हैं, और बिना अपवाद के अपवाद। लॉग आउटपुट की रिपोर्ट / विश्लेषण करें, क्योंकि यह आपको दिखाएगा कि आपकी साइट में प्रमुख मुद्दे कहां हैं।

अन्य

• सर्वर-साइड और क्लाइंट-साइड मॉनिटरिंग और एनालिटिक्स दोनों को लागू करें (एक प्रतिक्रियाशील के बजाय सक्रिय होना चाहिए)।
• अपने उपयोगकर्ताओं के साथ लगातार संपर्क में रहने के लिए UserVoice और Intercom (या अन्य समान उपकरण) जैसी सेवाओं का उपयोग करें।
• विन्सेन्ट Driessen की गिट शाखाओं वाली मॉडल का पालन करें

बहुत सारे सामान जरूरी नहीं हैं क्योंकि वे उपयोगी उत्तर नहीं हैं, लेकिन क्योंकि वे या तो बहुत विस्तृत हैं, दायरे से बाहर हैं, या किसी व्यक्ति को उन चीजों का अवलोकन करने के लिए बहुत दूर जाना चाहिए जो उन्हें जानना चाहिए। कृपया इसे संपादित करने के लिए स्वतंत्र महसूस करें, मुझे शायद कुछ सामान याद आ गया या कुछ गलतियाँ हुईं।

Comments

आपके कुछ एसईओ सुझाव खराब हैं। इससे कोई फर्क नहीं पड़ता कि आप टेबल या डिव का उपयोग करते हैं (Google ने स्वयं इसकी पुष्टि की है)। वह SEF URL बात ... मैं उन "नकली URL" से नफरत करता हूं, जहां ID एकमात्र ऐसी चीज है जो वास्तव में पृष्ठ निर्धारित करती है। "45-ब्लाह" एक ही पृष्ठ होगा। यह उपयोगकर्ता के अनुकूल नहीं है।

— असंतुष्टगीत

फिर इसे संपादित करें। मैंने इसमें से अधिकांश नहीं लिखा: मैं केवल इसे बनाए रख रहा हूं - एक नौकरी जो मुझे विरासत में मिली है क्योंकि मैंने सवाल पूछा था, विशेष रूप से इस बड़े जवाब की मांग की, और मैं वास्तव में यह देखने में दिलचस्पी रखता हूं कि हम क्या कर सकते हैं । बेहतर योगदान जितना अधिक होगा।

— जोएल कोएहॉर्न

एक और ध्यान दें: यदि आप वापस आते हैं और इसे संपादित करते हैं, तो जो लिखा गया था उसका सम्मान करने का प्रयास करें। केवल उन हिस्सों को न हटाएं जिनसे आप असहमत हैं: वास्तव में शॉर्ट-कॉमिंग को संबोधित करने और कुछ बेहतर प्रदान करने के लिए समय निकालें।

— जोएल कोएहॉर्न

एक बात जो मैं आपको अपने सुरक्षा अनुभाग में जोड़ने का सुझाव देता हूं, वह यह है कि आपके द्वारा सर्व की जाने वाली सभी फाइलों की अनुमति अनुमत फ़ोल्डरों के श्वेतसूची से, या वेबसर्वर को "जेल" करने के लिए की जानी चाहिए। यह किसी के उपयोग को रोकता है http://server/download.php?file=../../etc/password। उपयोगकर्ता के लिए फ़ाइल पथ को कभी भी उजागर न करें।

— फिलिपुमती

एक उदाहरण के रूप में, आप बस एक कार में नहीं कूदते हैं और ड्राइविंग शुरू करते हैं। इसके बजाय, आप उस कार के उचित संचालन पर कक्षाएं लेते हैं और अंततः आपको यह साबित करने के लिए एक परीक्षा उत्तीर्ण करनी होती है। कुछ के लिए, वह कई, कई, कई घंटे अध्ययन करता है । और हाँ, मैं यह सीखना चाहता हूँ कि कैसे ठीक से एक कार चलाना सीखने के साथ एक वेब एप्लिकेशन का निर्माण ठीक से नहीं किया जा सकता है क्योंकि एप्लिकेशन को ठीक से बनाने में विफलता निश्चित रूप से एक साधारण फेंडर की तुलना में लोगों के जीवन के विघटन का एक बड़ा हिस्सा हो सकता है, जिसमें बहुत बड़ा भी शामिल है वित्तीय क्षति। मौत? ठीक है, डेवलपर किस प्रकार के ऐप पर निर्भर करता है।

— NotMe